Security Misconfiguration

What Is Security Misconfiguration?

Security misconfiguration (OWASP API8:2023) is what happens when a security-relevant setting is left in an unsafe state: an over-permissive CORS policy, verbose error messages, debug features left on, default configs, or missing hardening. The code can be correct and the API still unsafe, because the way it is configured hands attackers an opening the application never intended. This exercise focuses on one of the most common and highest-impact cases: a cross-origin resource sharing policy that reflects whatever Origin a caller sends back into the Access-Control-Allow-Origin response header and sets Access-Control-Allow-Credentials to true. That combination tells a browser that any website may read the API's responses with the user's session cookie attached, so any page a signed-in customer opens can silently read their account. This exercise puts you on both sides. As Bob, an attacker who phishes consumer-app users, you read Corvexa's public developer docs, see that the account API advertises a browser-friendly CORS policy, and replay the request your malicious page will make: a call to the account endpoint with the Origin set to your own site. The API echoes your origin straight back and allows credentials, confirming that a page you control can read a logged-in user's account. You then weaponize a harmless reward page, adding a script that calls the account API from the visitor's browser with credentials included and ships the account data to your own server, so a victim only has to open the link. As Alice, the backend engineer who owns the API's configuration, you get the breach alert, open the CORS middleware, and see it trusting the caller's origin and allowing credentials with no allow-list at all. You ship the fix: restrict Access-Control-Allow-Origin to an explicit allow-list of Corvexa's own web origins, and never pair a reflected or wildcard origin with credentials. Replaying the attack proves it holds, with the crucial nuance that a plain HTTP client still gets the data while a real browser, seeing no permission header for an unknown origin, refuses to expose the response to the attacker's page. The exercise closes with quiz questions on why reflecting an origin with credentials is unsafe, why the fix is an allow-list rather than fewer fields or rate limiting, and why CORS is enforced by the browser rather than 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.