Production Hardening, OWASP Top 10 & Best Practices
Every prior chapter built one mechanism correctly in isolation. This closing chapter maps those mechanisms onto the OWASP API Security Top 10 and the real mistakes teams actually ship to production.
Learning objectives
- Beginner: Map at least three OWASP API Security Top 10 categories to the Spring Security mechanism that addresses them.
- Intermediate: Recognize the common production mistakes this chapter lists in a real codebase you're reviewing.
- Advanced: Run a production-hardening checklist against a real Spring Security configuration and identify concrete gaps.
🌱 BEGINNER STORY
Everything so far has been about designing and building a secure structure. But before any real building opens to the public, a building inspector walks through with a checklist — fire exits clearly marked, no exposed wiring, alarms tested, doors that lock properly under real conditions, not just on the blueprint. This chapter is that final walkthrough: the practical, battle-tested checklist real teams use before letting real traffic hit a Spring Security-protected application in production.
| OWASP API Risk | Spring Security Angle & Mitigation |
|---|---|
| BOLA (Broken Object Level Authorization) | The #1 API risk — a user accesses another user's resource just by changing an ID in the request (e.g., GET /api/accounts/124 instead of their own /123). Spring Security's authentication doesn't automatically prevent this — YOU must add ownership checks (e.g., @PreAuthorize with a SpEL check against the resource owner, or scoped repository queries). |
| Broken Authentication | Weak password policies, missing rate-limiting/lockout, predictable tokens. Mitigate with strong PasswordEncoder choices, CompromisedPasswordChecker, and account lockout via UserDetails.isAccountNonLocked(). |
| Broken Object Property Level Authorization (Mass Assignment) | Binding a @RequestBody directly to a JPA @Entity can let an attacker set fields they shouldn't (e.g., role=ADMIN in the JSON body). Always bind to a dedicated DTO, never the entity directly. |
| Unrestricted Resource Consumption | No rate limiting lets attackers exhaust resources (login brute-force, expensive endpoint abuse). Mitigate at the gateway/API layer with rate limiting (e.g., Bucket4j, or an API gateway feature). |
| Broken Function Level Authorization | An admin-only function is reachable by a regular user because a check was only added at the UI layer, not the backend. Always enforce with @PreAuthorize / requestMatchers on the SERVER, never rely on hiding a button in the frontend. |
| Server-Side Request Forgery (SSRF) | The server fetches a URL supplied (directly or indirectly) by an attacker, potentially reaching internal-only endpoints (like cloud metadata services). Mitigate with strict allowlists for any outbound URL fetching. |
| Security Misconfiguration | Default credentials left active, verbose error messages leaking stack traces, unauthenticated actuator endpoints (/env, /heapdump). Mitigate with custom exception handlers, securing actuator, and removing default users/passwords before production. |
| Unrestricted Access to Sensitive Business Flows | A legitimate endpoint (checkout, coupon redemption, account creation) is automated at scale by a bot to gain unfair advantage — buying up all inventory, mass-creating accounts, scraping. The endpoint's authorization is correct; what's missing is friction against automation. Mitigate with CAPTCHA, rate limiting, and anomaly/bot detection specifically on business-critical flows, not just the login endpoint. |
| Improper Inventory Management | Old, undocumented, or 'temporary' API versions/endpoints left running and unmonitored, becoming forgotten attack surface. Mitigate with API versioning discipline and regular endpoint audits. |
| Unsafe Consumption of APIs | Blindly trusting data returned from a third-party API integration without validation. Mitigate by validating and sanitizing all external API responses just as you would user input. |
⚠ Recurring anti-patterns
Exposing full stack traces in error responses — reveals internal class names, library versions, and sometimes SQL queries; use @ControllerAdvice with a ProblemDetail response that strips internals in production profiles. Missing security response headers — X-Frame-Options (clickjacking), X-Content-Type-Options (MIME sniffing), Content-Security-Policy (XSS). Spring Security's headers() DSL enables sane defaults, but teams often disable them 'to make an iframe work' without a scoped, deliberate exception. Logging sensitive data — passwords, tokens, or PII ending up in application logs (even at DEBUG level) is a frequent, embarrassing incident; scrub/mask sensitive fields in logging configuration. Trusting X-Forwarded-For blindly for IP-based logic (rate limiting, geo-blocking) — this header is fully attacker-controlled unless your reverse proxy/load balancer is configured to strip and re-set it correctly. Running old TLS versions (1.0/1.1) still enabled at the load balancer/ingress level, vulnerable to known protocol-level attacks — enforce TLS 1.2+ only. Enabling Spring Boot Actuator's full endpoint set (/env, /heapdump, /shutdown) without authentication on a publicly reachable port — restrict actuator to an internal-only network/port, or secure it explicitly.
✅ Before you ship
Enforce HTTPS everywhere (requiresChannel().anyRequest().requiresSecure()), with HSTS enabled. Set short-lived access tokens + rotated refresh tokens; monitor for refresh-token reuse (a sign of theft). Run a SAST tool (e.g., SonarQube with security rules) in CI, and a DAST tool (e.g., OWASP ZAP) against a staging environment before every major release. Put a Web Application Firewall (WAF) in front of the application with OWASP Core Rule Set enabled. Restrict Actuator endpoints to an internal network/management port, and never enable /shutdown or /heapdump publicly. Review and remove any 'temporary' permitAll() rules added during development before shipping. Conduct periodic red-team/penetration testing exercises against your own application.
Want a visual for this concept?
Generate a diagram tailored to “Production Hardening, OWASP Top 10 & Best Practices” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.
Sign in to generate a visual →