API8:2023 — Security Misconfiguration

Slide 17 · The Pattern

Every scenario had a control that existed but wasn’t applied correctly.

CORS, error handling, method restrictions — all available in the framework. All misconfigured.

The Missing Question

Every API8 failure omitted: “Does this configuration represent the minimum necessary access, with all debug features off, and all controls explicitly set — not just left at defaults?”

Not “does the feature work?” — it did. Not “is the code correct?” — it was. Specifically: is this configuration appropriate for a production system that faces the internet?

Failure in each scenario

CORS — reflected any origin instead of validating against a fixed allowlist

Verbose errors — debug mode left on in production; framework default exposed internals

DELETE method — no method restriction; framework routed to a dev-only handler in production

The fix pattern

Set configuration explicitly for production — never rely on defaults

Disable debug mode and verbose errors in all non-development environments

Allowlist permitted HTTP methods per endpoint — block everything else at the framework or routing layer

Validate configuration as part of deployment — not just code

Treat configuration as a security control, not an operational detail

← Back How do we fix it? →