4.3 Cross-Boundary Requests: CSRF, CORS, and SSRF

CSRF and SSRF both allow an authenticated component to send requests on behalf of an attacker, but they do so through different proxies: CSRF uses credentials automatically carried by the user's browser, while SSRF exploits the server's network position and service identity. CORS primarily controls whether browser scripts can read responses from different origins.

CSRF Doesn't Disappear Just Because SameSite Is Enabled

With cookie authentication, the browser may attach credentials to cross-site requests. Protection should combine:

• Use semantically unsafe methods such as POST/PUT/PATCH/DELETE for state changes, keeping them out of GET/HEAD. Here "unsafe" is the HTTP classification for state changes; POST alone does not prevent CSRF;
• SameSite=Lax/Strict set according to product workflow;
• Use a session-bound synchronizer token or a signed double-submit token bound to the session with HMAC. Merely comparing two equal values that an attacker can plant is insufficient;
• Verify Origin; if necessary, use Referer as a compatibility signal;
• Re-authenticate high-risk transactions and display transaction details;
• Do not trust untrusted subdomains merely because they are same-site.

SameSite=None scenarios must be used in conjunction with Secure, and require full token/Origin protection. CSRF during login, OAuth callback, and cross-site embedding flows must be modeled separately, never disable defenses globally just to make one integration work.

CORS is a response reading policy

The server tells the browser via the CORS response header which origins' scripts can read the response:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Vary: Origin

For a request with credentials mode include, Access-Control-Allow-Origin: * does not authorize browser access to the response. The request and cookies may still have been sent. Before reflecting Origin dynamically, match it against a normalized exact allowlist, and endsWith("example.com") cannot be used to accept attackerexample.com.

For example, a plain cross-site form POST can be sent without preflight; when SameSite permits cookies, the server may receive authenticated credentials. Blocking response access through CORS cannot undo a completed transfer.

Preflight is not authentication, and non-browser clients can send requests directly. APIs must still validate identity, authorization, content type, and CSRF conditions. Misconfiguring CORS can expose responses to browser scripts; it does not replace network ACLs that restrict who can connect to the service.

SSRF makes the server into a network proxy

Typical entry points include URL previews, webhook testing, avatar scraping, PDF rendering, cloud imports, and "install plugin from URL." Attackers may access:

• loopback, private, link-local, and cloud metadata;
• Management plane and database agents open only to internal networks;
• Unix socket or a non-HTTP scheme;
• Targets bypassed via redirect, DNS rebinding, IPv6/mixed encoding.

The best defense is never to accept arbitrary URLs: have users select an integration/object ID registered on the server. If the business truly needs outbound fetching, establish a dedicated egress fetcher.

1. Only allow https and other essential schemes;
2. Strictly parse hostname, port, userinfo, and IP literal;
3. Check all A/AAAA results, reject loopback, private, link-local, multicast, and other disallowed special addresses, and handle IPv4-mapped IPv6 consistently. Checking only the first result is insufficient;
4. Connect to a verified IP without allowing the client library to resolve again; TLS must still verify the original hostname and send the correct SNI. Recheck every redirect target;
5. Block metadata, management network, and unnecessary internal networks using network policies;
6. Limit response size, type, time, redirect count, and concurrency;
7. The fetcher does not carry the caller's Cookie, cloud credentials, or internal authentication headers;
8. Record the final IP, domain, response size, and rejection reason.

A domain allowlist narrows the scope compared with accepting arbitrary URLs, but it still needs to handle hijacked subdomains, DNS changes, and vendor redirects. Relying solely on regex to block 127.0.0.1 will miss IPv6 addresses, integer IPs, and resolved private network addresses.

Webhooks Require Reverse Boundary Control

When sending a webhook, the target URL introduces SSRF risks; when receiving a webhook, spoofing and replay attacks are the primary concerns. Follow the sender's protocol to verify the HMAC/signature over the raw body bytes and any signed timestamp and event ID. Apply canonicalization only when that protocol explicitly defines it; the receiver cannot invent a "normalized raw body."

Do not JSON-parse and reserialize before verification: whitespace, field order, and number representations can change the bytes. Compare HMACs in constant time and enforce a replay window. After verification, insert the uniquely constrained event ID and pending work or outbox record in one transaction before acknowledging receipt. Recording an idempotency key and then enqueueing separately can lose the event after a crash. Consumers also need idempotent business effects so a retry does not charge twice. Error responses should not reveal signature-comparison details.

Narrow the Browser Attack Surface with Security Response Headers

Based on product usage:

Content-Type: application/json
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Content-Security-Policy: frame-ancestors 'none'

HSTS is enabled gradually only after confirming that the entire domain and selected subdomains consistently support HTTPS and have certificate emergency capabilities; incorrect long-term includeSubDomains can lead to persistent availability incidents.

Boundary Testing Matrix

CSRF: Cross-site form submissions, fetch requests, malicious subdomains on the same site, missing or invalid tokens, and incorrect Origin
CORS: allows/denies origin, null origin, credentials, and cache Vary
SSRF: IPv4/IPv6 private networks, redirect, DNS changes, metadata, massive responses
Webhook: Signature tampering, expired timestamp, duplicate event, body encoding differences

The next chapter starts after an application exploit has granted process execution and examines the limits the operating system can still enforce.

References

• OWASP, CSRF Prevention Cheat Sheet
• Fetch Standard, CORS protocol
• OWASP, SSRF Prevention Cheat Sheet
• OWASP, HTTP Headers Cheat Sheet