Server fetches need destination policy

A server fetch uses the server’s network position, not the browser’s.

Authority travels with the worker

A picture-import service retrieves content on a person’s behalf. Permission to use that feature does not imply permission to choose any destination the service could reach. An egress policy limits outbound communication from the worker; application-level destination checks express the feature’s narrower business rules.

A redirect is a response that directs retrieval elsewhere. Checking a destination once does not establish a policy for subsequent destinations. Noticing a redirect only after completion is too late to prevent a connection that already happened.

Fictional import review

Assume a museum imports images only from its two contracted media providers. Those providers support direct HTTPS retrieval; this feature does not require redirects.

• F1: Editors are authenticated and authorized to import images. The first destination is checked against the approved provider list.
• F2: The worker follows redirects; the design gives no policy for them.
• F3: Network restrictions and maximum response size have not been reviewed. A ten-second timeout is documented.

Close the specific gaps

F1 supports the initial business check. It does not resolve F2 or F3. For the stated requirements, rejecting redirects is a proportionate design choice. Document outbound restrictions consistent with the provider policy and verify that the actual connection obeys them.

Also establish response-size and processing limits, and treat received content according to the image workflow. A trusted provider relationship does not guarantee every response is a valid image. A timeout bounds one resource dimension, not destination authority or total memory use.

Approval note: Initial authorization documented; destination coverage and response limits remain pending.