Slide 14 of 28
Part 3 · Attack ScenariosSlide 14
PART 3
Attack Scenarios
Slides 14–17 · OWASP examples in plain English
Slide 14 · Scenario 1
Any website can read your users’ API data. The CORS config made it so.
OWASP Scenario #1 — CORS misconfiguration allowing any origin with credentials.
📄 OWASP API Security Top 10 · 2023 · API8 · Scenario 1
SETUP
A banking API with a misconfigured CORS policy.

A banking application’s API is used by a web frontend at https://bank.example.com. The API uses session cookies for authentication. To handle requests from the frontend, the API needs CORS headers.

A developer configured the CORS policy to read the Origin header from every request and reflect it back in the response — a pattern intended to support multiple frontends. The configuration also sets Access-Control-Allow-Credentials: true to allow cookies to be sent.

Result: every origin is permitted to make authenticated cross-origin requests to the API.

The exploit: An attacker registers attackersite.com and hosts a page with JavaScript that fetches https://api.bank.example.com/account/balance with credentials included. They send the link to victims via email or social media. Any victim who is logged into the banking app and clicks the link will have their account balance, transaction history, and other sensitive data silently sent to the attacker’s server. The victim sees a blank page or a redirect. The data theft is invisible.
The null origin bypass

Some implementations also grant access to Origin: null — a value sent by sandboxed iframes, local HTML files, and certain redirect scenarios. An attacker can trigger a null origin by embedding an iframe with sandbox attribute. If the API grants access to null origins, this is an additional bypass that often gets overlooked.

← Back Scenario 2 →