Security Misconfiguration

What Is Security Misconfiguration?

The code is correct and the API is still unsafe, because a security-relevant setting is left in a dangerous state. This one is CORS: the API reflects whatever Origin a caller sends into Access-Control-Allow-Origin and sets Access-Control-Allow-Credentials to true, telling browsers that any site may read its responses with the visitor's session cookie. You'll weaponize a reward page that ships the account API's response to your server, then restrict allowed origins to an explicit server-side list. Replaying it shows that CORS is enforced by the browser, not the server.

What You'll Learn in Security Misconfiguration

• Recognize security misconfiguration in an API: a security-relevant setting left unsafe, such as an over-permissive CORS policy, verbose errors, debug flags, or default configuration
• Understand why reflecting the request Origin into Access-Control-Allow-Origin and allowing credentials lets any site a signed-in user visits read their account with their session cookie attached
• See how an attacker proves the misconfiguration with a single request, then weaponizes an ordinary-looking page so a victim only has to open a link for their account to leak cross-origin
• Distinguish it from broken object level authorization (a missing per-record ownership check) and excessive data exposure (over-returning fields); here the handler is fine and the flaw is the configuration
• Apply the fix: restrict allowed origins to an explicit server-side allow-list, never pair a reflected or wildcard origin with credentials, and understand that a browser, not the server, is what enforces CORS

Security Misconfiguration — Training Steps

1. A browser-friendly API

   Corvexa is a personal-finance app: people link their bank and track their spending, and the Corvexa web app reads their account from Corvexa's API right in the browser. Today Bob is targeting Corvexa. He wants customer account data he can phish and resell. He has a throwaway Corvexa account of his own, and he starts on the public developer docs to see how the API is exposed to the browser.

2. Any site is allowed

   One card in the docs describes how the API treats requests coming from other websites. Bob reads it closely.

3. Ask as the attacker's site

   Bob replays the request his malicious page will make. He points an API client at the account endpoint and, exactly as a browser would, sets the Origin header to his own site. He is signed into his own throwaway Corvexa account, so the request carries a real session. What he cares about is not the body, it is what the API tells the browser it may do with the response.

4. The API says yes

   Look at the response headers the API sent back with the account.

5. The lure page

   Bob builds a harmless-looking page to host on his own site: a Corvexa reward banner. It renders in the browser on the left; its source is open in the editor on the right. On its own it does nothing but show a $50 offer.

6. Weaponize the page

   Now Bob adds the payload. The banner will look identical to a visitor, but the page will quietly call Corvexa's account API from their browser and ship whatever comes back to his own server. Because the API allows his origin with credentials, the visitor's cookie does the rest.

7. How the theft works

   The page still shows only the reward to a visitor. Walk through what the added script does the moment a signed-in Corvexa customer opens it.

8. Send the bait

   The trap is ready. Bob only needs a signed-in Corvexa customer to open it, so he emails the reward link to one, dressed up as a genuine Corvexa promotion from his lookalike domain.

9. A reward in the inbox

   You use Corvexa yourself, and right now you are signed into your account in your browser. An email lands offering a $50 Corvexa reward. The offer sounds plausible and the branding looks right.

10. Open the link

    You click through to claim the reward, the way most people would. The page opens in your browser, still carrying your live Corvexa session.