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 leverages the 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

If cookie authentication is used, the browser might automatically include it in requests triggered by cross-site requests. Protection should combine:

• State changes use only non-safe HTTP methods;
• SameSite=Lax/Strict set according to product workflow;
• Use a synchronized token from a bound session or a controlled double-submit token;
• Verify Origin; if necessary, use Referer as a compatibility signal;
• Re-authenticate high-risk transactions and display transaction details;
• Don't trust cross-site untrusted subdomains.

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

Credentials are not allowed when using *. Dynamic reflection Origin must match the normalized exact allowlist before being accepted, and endsWith("example.com") cannot be used to accept attackerexample.com.

CORS is not an authentication mechanism, and non-browser clients cannot directly send requests. APIs must still validate identity, authorization, content type, and CSRF conditions. Misconfiguring CORS typically leaks data readable by browsers; 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. After DNS resolution, reject loopback, private, link-local, and multicast addresses;
4. Bind a verified IP during connection establishment and verify the new target on each redirect;
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.

The domain allowlist is better than any URL-based approach, 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. The receiving end should validate HMAC/signatures, timestamps, event IDs, and normalized raw body, and then asynchronously process it after persisting an idempotency key.

Don't JSON parse and then re-serialize for signing; different whitespace, field order, or number representations will change the bytes. Also, don't leak details of signature comparison in error responses.

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 begins with an application vulnerability that has already granted the attacker process execution privileges and explores how the operating system continues to restrict the attacker.

References

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