Server-side trust boundaries

A helpful feature can cross a boundary on a user’s behalf: fetch a picture, render a document, or rebuild an object. The server’s location and permissions may differ from the user’s. Secure design makes the permitted work explicit rather than granting every request all of that authority.

URL fetchers: network reach is not identity

SSRF concerns unintended server-side requests, not every feature that accepts a URL. A fetch may originate from a privileged network location without carrying any application credentials. Other fetchers deliberately attach credentials, use a proxy, or assume a workload identity. Network source and authenticated identity are separate facts.

Permit only required schemes and destinations. Account for DNS resolution, address ranges, redirects, and differences between validation and the actual connection. Disable redirects when unnecessary, or apply the same policy at each destination. Restrict the fetcher’s network access and credentials as a second layer. OWASP’s SSRF guidance explains why URL checks alone can be incomplete.

A metadata service requiring an additional token can block some request patterns. Receiving an error does not automatically demonstrate credential exposure, nor prove the whole fetch feature safe.

Scenario: the newsletter preview

The newsletter service fetches images through a restricted worker and renders a fixed template using supplied data. An image fetch fails. The team records which component rejected it and why; it does not infer internal access or stolen credentials from the status alone.

For templates, the key distinction is data versus template instructions. Autoescaping helps with rendered HTML, but does not prevent a template engine from evaluating untrusted template source. Capabilities and impact vary by engine and configuration.

Includes and XML have their own controls

SSI is interpreted by a configured origin server; ESI fragment processing may occur at a proxy, cache, or other configured processor. Their presence does not automatically establish arbitrary fetch or execution.

XXE concerns XML external entities. XSLT transforms XML and may have separate resource-access or extension features. Disabling DTD processing does not necessarily disable stylesheet imports or every external fetch. Review the precise parser and transformer settings, resource limits, and supported versions.

Deserialization: authenticity is only one question

Object deserializers may invoke application behavior while reconstructing objects. Prefer simple data formats and explicit schemas over accepting arbitrary runtime object graphs. A signed blob can protect integrity when correctly verified, but does not make an unsafe deserializer safe for every trusted producer or every allowed value.

Review the producer, integrity checks, allowed types, resulting actions, and execution authority separately. Evidence-led conclusions name the specific boundary and observed behavior without assuming that every parsing issue leads to code execution.

Read a preview service’s boundary records

The fictional newsletter permits image retrieval only from its approved media catalog. Its owner supplies three records: S1 validates the initial destination; S2 follows redirects without applying that destination policy again; S3 shows the worker carries no customer session cookies. A fixed template receives the newsletter text as data.

S1 establishes an initial check. S2 leaves subsequent destinations outside that check. S3 limits one form of credential exposure, but does not constrain where the worker can connect. These are separate controls: destination selection, network reach, attached identity, and interpretation.

PredictThe worker sends no customer cookies. Can the reviewer therefore approve its destination restriction?

Cookie absence does not establish destination enforcement. The feature should either avoid unnecessary redirects or enforce its permitted-destination policy across every followed step, with the worker’s network access constrained accordingly.

The owner then supplies a new validation result: the worker refuses a redirect outside the catalog before connecting to the redirected destination and records a policy reason. That supports enforcement for this case and configuration. It does not demonstrate every address-resolution case, every redirect, or historical absence of unintended requests. Keep the acceptance scope explicit.

Apply the same reasoning to a separate XML conversion stage. A record that external DTD loading is disabled answers one parser question. It does not establish a stylesheet processor’s import policy, extension capabilities, or resource budget. Review the actual components and the work each can perform.

For templates, choose a fixed instruction source and pass user content as data. For reconstructed objects, prefer a limited data schema and explicit operations. A valid signature can establish integrity under a trusted key; it cannot decide that every permitted producer, object type, and resulting operation is appropriate.

The practical deliverable is a boundary table: operation, allowed resources, effective identity, interpreter, and verification evidence. A generic statement that the preview is secure would hide the unresolved parts.