OWASP's security misconfiguration risk is mostly a checklist: lock down environments repeatedly, review configuration, use TLS, allow only needed methods, set a CORS policy, accept only needed content types and hide stack traces. This post maps those items to what to verify in Spring, FastAPI, NestJS and Rails.
What OWASP lists
The API8:2023 page names common causes such as missing hardening, unnecessary enabled features, missing TLS, absent cache control headers, weak CORS and error messages that reveal stack traces. Its prevention advice includes a repeatable hardening process, automated configuration checks in all environments, encrypting all API communication with TLS, permitting only needed HTTP methods, a proper CORS policy for browser facing APIs, and defined response schemas including errors.
The checklist by framework
| Item | What to verify | Where to look |
|---|---|---|
| Unnecessary features | Docs and management endpoints off or protected | FastAPI openapi_url, springdoc properties, NestJS ui and raw, Spring actuator exposure |
| CORS | Explicit origins, no wildcard with credentials | FastAPI CORSMiddleware rules, Spring Security CORS setup |
| HTTP methods | Only needed verbs routed | Route definitions in each framework |
| Request validation | Unknown fields rejected or stripped | NestJS ValidationPipe whitelist, Rails strong parameters, Pydantic models |
| Response shape | Declared output models, no internals | FastAPI response_model, serializers elsewhere |
| Errors | No stack traces in responses | Framework error handlers and profile settings |
| TLS | Enforced at proxy or app | Load balancer and app config |
| CSRF | Matches your auth style | Spring and Rails settings |
Facts from the framework docs worth knowing: Spring Boot exposes only the health endpoint over HTTP by default, but exposing everything with a wildcard is possible and the docs advise securing it. FastAPI's CORS defaults are restrictive and, with credentials enabled, wildcards are not allowed for origins, methods or headers. NestJS's ValidationPipe can strip properties without validation decorators when whitelist is true, and reject them with forbidNonWhitelisted.
Steps to run the checklist
- Pick one service. Do not try all at once.
- Build a short table like the one above with the actual setting values.
- Check each setting in the production profile, not in your local one.
- Request the risky paths from outside and record status codes.
- Trigger an error on purpose, such as malformed JSON, and read the response body.
- Fix gaps in configuration, commit them, and add a check in CI.
- Repeat per service and keep the table with your API inventory.
Environment drift is the real enemy
Most misconfigurations come back. A staging profile gets copied, a debug flag is left on, a wildcard is added for a demo. OWASP's advice to assess configuration effectiveness continuously with automated checks is the answer, not a one time review. See a CI test for docs endpoints for a small example, and Spring Boot actuator endpoint exposure for the management side.
Try it yourself
Click through it at your own pace, or open it full screen. Look for findings about configuration rather than code.
Safeguard's policies and gates can enforce checks in your pipeline, and a free scan covers dependencies.
Quick check
Is a stack trace in an error response a misconfiguration?
OWASP lists error messages that reveal stack traces among common causes. Define error response schemas and hide internals.
How often should I recheck?
Continuously through automated checks in CI, plus after any environment or profile change.
Sources
- OWASP API8:2023 Security Misconfiguration
- Spring Boot actuator endpoints
- FastAPI: CORS
- NestJS validation
Last reviewed: 19 October 2026.
