API8:2023 — Security Misconfiguration

QUESTION 01 OF 05

What is the key difference between API8 Security Misconfiguration and the other nine OWASP API risks?

Correct — this distinction matters for where you look for the fix. If a BOLA vulnerability exists, you fix the authorization check in the code. If a CORS misconfiguration exists, you fix the CORS policy in the server config — no code change needed. API8 is the category that lives in environment variables, web server configs, framework settings, and infrastructure configuration — not in application code. This is why it’s often missed: code review doesn’t catch it, and it requires dedicated configuration review and automated scanning.

Not quite — the key distinction is where the fix lives. API8 misconfigurations are fixed by changing configuration: CORS headers, debug mode flags, TLS settings, endpoint exposure. The other OWASP risks require fixing application code: authorization logic, authentication implementation, input validation. This means API8 requires different detection methods (configuration scanning, header analysis) rather than code review alone.

QUESTION 02 OF 05

An API sets Access-Control-Allow-Origin to whatever value is in the incoming Origin header, and also sets Access-Control-Allow-Credentials: true. Why is this dangerous?

Correct — the browser’s Same-Origin Policy normally blocks JavaScript on attacker.com from reading responses from api.yourapp.com. CORS headers are how the API grants exceptions to this rule. When the API reflects any origin and allows credentials, it grants the exception to every origin — including the attacker’s. The browser sees: “The API said attacker.com is allowed, and credentials are permitted.” So it sends the session cookie and allows the attacker’s JavaScript to read the response. This is why the fix must be a strict allowlist — only explicitly permitted origins should receive the CORS grant.

Not quite — the browser’s Same-Origin Policy blocks cross-origin JavaScript responses by default. CORS headers are the exception mechanism. When the API reflects the caller’s Origin header, it grants the exception to every caller — the attacker’s JavaScript on attacker.com sends the victim’s cookie, gets the API response, and reads it. Allow-Credentials: true enables cookies to be sent cross-origin. Together: attacker’s site + victim’s cookie + any API response — complete cross-origin account access.

QUESTION 03 OF 05

A production API returns a 500 error that includes: SELECT * FROM user_accounts WHERE email = ’test’ AND active = 1. Beyond exposing the table name, what additional risk does this create?

Correct — verbose SQL errors are SQL injection roadmaps. Without the error, an attacker must blindly probe: try various payloads, infer from response times (blind SQLi), and slowly reconstruct the query structure. With the error message, the attacker already knows the table name, column names, query structure, and exactly where their input is inserted. They can craft a working injection payload in the first or second attempt instead of spending hours on blind enumeration. The verbose error doesn’t create the SQL injection — it makes the existing SQL injection trivially exploitable.

Not quite — the immediate risk is accelerated SQL injection. The error reveals the query structure, table name, and column names. An attacker who suspected SQL injection now has a map: they know what the query looks like around their input, so they can craft a working injection payload immediately instead of spending hours on blind probing. The verbose error turns a potential vulnerability into a confirmed, easily exploitable one.

QUESTION 04 OF 05

In the Tesla 2018 incident, what was the primary misconfiguration that enabled the breach?

Correct — the root cause was a single deployment configuration decision: the Kubernetes dashboard was accessible from the internet without authentication. This is a textbook API8 failure — no code bug, no exploit chain. The dashboard worked exactly as designed — it was just deployed with no access control. Once inside the dashboard, the AWS credentials were visible as environment variables in the pod configuration — a second misconfiguration (credentials in environment variables visible to anyone with dashboard access). Two configuration failures, compounded.

Not quite — no SQL injection, no brute-forced credentials, no expired certificate. The Kubernetes dashboard was simply deployed with no authentication and exposed on the internet. Anyone who found the URL had full admin access. This is the purest form of API8: the software worked correctly, but the deployment configuration omitted the authentication control entirely. The AWS credentials were a secondary issue — they were visible through the unauthenticated dashboard.

QUESTION 05 OF 05

Why is automated configuration scanning in CI/CD (MIT 07) more effective than manual configuration review?

Correct — the core value of automated scanning is catching regressions in real time. Configuration drift happens: someone changes a CORS policy to debug a complaint, someone enables verbose errors on a staging server that later becomes production, someone deploys a new endpoint without setting security headers. Manual reviews are point-in-time; they can’t catch changes made after the review. An automated scan that runs on every deployment catches these changes the moment they occur — before they reach production users. This is the same principle that makes automated testing valuable for code — applied to configuration.

Not quite — the primary value is catching regressions continuously, not capability beyond human ability. Security configuration can be correctly set in a manual review on Monday, then accidentally changed by a debugging session on Tuesday, and be wrong when it ships on Wednesday. A manual reviewer checking monthly would miss this entirely. An automated scan running on every deployment catches it in the deployment that introduced the change. Automation makes configuration review continuous rather than periodic.