Building Secure Java REST APIs: The Checklist I Use on Every Engagement

Every request body, path parameter and query string is untrusted. In Spring that means Bean Validation annotations on request DTOs and a global exception handler that turns violations into a consistent 400 rather than leaking a stack trace. The important discipline is validating into a DTO, never binding a request directly onto a persistence entity.

Binding straight to an entity is how mass-assignment vulnerabilities happen: a caller supplies a field like role or accountId that was never part of the intended form, and it is silently persisted. An explicit DTO with only the fields the endpoint accepts makes that structurally impossible, which is far better than remembering to check.

SQL injection remains common in code that builds queries by concatenation, usually in a dynamic search or an ORDER BY clause where a parameter cannot be bound. Named parameters everywhere is the rule; for sort columns, map the user input through an allowlist to a known column name rather than interpolating it.

Deserialisation deserves the same suspicion. Configure the JSON mapper to reject unknown properties, avoid polymorphic type handling driven by data in the payload, and never deserialise into a type that can trigger side effects on construction. This class of bug is less common than SQL injection and considerably more severe when it lands.

For token-based auth, verify the signature with the expected algorithm rather than trusting the algorithm named in the token header — accepting the header's claim is the classic algorithm-confusion flaw. Check expiry, issuer and audience, and reject anything that fails any of those, with the same generic error so the response does not become an oracle.

Keep access tokens short-lived and refresh tokens revocable. And make the security configuration deny-by-default: any endpoint not explicitly permitted requires authentication. The opposite arrangement means a newly added controller is public until someone remembers to secure it, and eventually someone will not.

Route-level checks answer whether this user may call this endpoint. They do not answer whether this user may act on this record. Broken object-level authorisation is, in my experience, the single most common serious flaw in otherwise well-built enterprise APIs: an authenticated user changes an ID in the path and reads someone else's data.

The fix is to scope every query by the requesting principal rather than fetching by ID and then checking ownership afterwards. Fetching first and checking second still leaks information through timing and error differences, and it is one forgotten check away from a breach. Scoping the query makes the safe path the only path.

Rate limit by authenticated identity where possible and by IP otherwise, with tighter limits on expensive endpoints and on authentication itself — unlimited login attempts are a credential-stuffing invitation. Cap request body size and collection lengths too, because an endpoint that happily accepts a 50MB array is a denial-of-service vector.

Errors should be helpful to legitimate clients and useless to attackers. Return a stable error code and a generic message; log the detail server-side with a correlation ID the client can quote to support. Stack traces and database messages in responses are a reconnaissance gift, and they are still shipped by default in more services than they should be.

Secrets belong in a secret manager, injected at runtime, never in source or a committed properties file. Rotation should be a routine operation rather than an incident response, which in practice means the application must tolerate a credential changing without a redeploy.

Dependency scanning belongs in CI and should fail the build on known-vulnerable versions — the majority of real-world compromises I have reviewed came through a dependency, not through bespoke code. Finally, log security-relevant events: authentication outcomes, authorisation denials, and changes to sensitive records, with actor, action, target and timestamp. That audit trail is what turns an incident from a guess into an investigation.