CORS Null Origin With Credentials: From Sandbox to Data Theft

CORS Null Origin With Credentials: From Sandbox to Data Theft

Some APIs treat Origin: null as trusted. Browsers send that origin from sandboxed iframes, local files, data URLs, and a few privacy-sensitive contexts. If the response also carries Access-Control-Allow-Credentials: true, an attacker page may read authenticated data.

Seeing Access-Control-Allow-Origin: null in Repeater is not the finish line. You need a browser proof because cookie policy, SameSite behavior, preflights, and endpoint sensitivity decide whether anything leaks.

Reproduce the server decision

Take an authenticated GET that returns private JSON, then replace its Origin:

Origin: null

Look for both:

Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true

Wildcard ACAO with credentials is blocked by browsers, so * is not equivalent. The literal null response is the dangerous pattern. Check whether the API sets Vary: Origin; missing it may add cache trouble, though it is not required for the core read.

Browser PoC, not wishful thinking

Host an HTML page on your domain. Create an iframe with sandbox="allow-scripts" but without allow-same-origin; scripts inside get an opaque origin serialized as null. The framed document calls the target API with fetch(url, { credentials: "include" }) and sends the response text to the parent or your collector.

Use your own account and exfiltrate a canary field, not a real user's records. If the cookie is SameSite=None; Secure, it will usually accompany the cross-site request. Lax or Strict cookies may block it. Some authentication uses bearer tokens stored in JavaScript instead of cookies; your sandbox does not magically gain those tokens.

Preflight can also stop the chain. Begin with a simple GET requiring no custom headers. For JSON POSTs, inspect OPTIONS and verify the server allows the method and requested headers. A readable profile endpoint is often enough to prove confidentiality impact without changing state.

One trap: opening the exploit HTML directly from disk may also produce a null origin, but that is a poor victim story. The sandboxed HTTPS page proves an attacker can deliver the condition remotely. Keep both tests separate in your notes so local-file behavior does not inflate the finding.

Where null origins appear legitimately

Developers sometimes whitelist null for desktop apps, file-based frontends, PDF viewers, or sandboxed widgets. That business requirement still should not grant ambient cookie access to a broad API. Give trusted clients scoped tokens or a dedicated origin instead.

Check the rule across:

• /api/me, billing, addresses, and export endpoints
• Alternate API hostnames used by mobile clients
• GraphQL POST and persisted-query GET routes
• Error responses, which sometimes expose stack traces under the same policy

Do not report public catalog data as account theft. Name exactly what your browser read and which session cookie was sent.

Recommended remediation is a strict allowlist of concrete HTTPS origins, no null entry for credentialed resources, and server-side authorization independent of Origin. OWASP's CORS guidance explains safe policy design. PortSwigger's CORS material includes sandbox null-origin exploitation. The information exposure often maps to CWE-942. Attach the working HTML and browser console output; raw headers alone leave too many unanswered questions.