Skip to content

Security Error Boundaries

Security objective

Return stable client behavior while revealing as little as possible about credentials, accounts, authorities, policies, and implementation details.

Spring Security model

Many security failures happen in the servlet filter chain before controller invocation. ExceptionTranslationFilter converts them through two extension points:

Situation Spring API Typical API status
Authentication absent or invalid AuthenticationEntryPoint 401
Authenticated but unauthorized AccessDeniedHandler 403

Controller advice handles exceptions raised after controller dispatch; it does not replace filter-boundary handlers.

Browser chains may redirect to login while stateless API chains return JSON. Configure behavior per chain and client contract.

Safe error schema

A bounded schema can contain status, stable machine code, generic message, and normalized request path. It should omit exception messages, stack traces, token data, authorities, policy expressions, account existence, and internal class names.

Detailed diagnostics belong in protected logs using bounded error categories and correlation identifiers. Credentials, assertions, authorization codes, cookies, and full tokens must never be logged.

Trust and failure cases

  • Returning 403 for every missing credential
  • Serializing parser exception text
  • Returning granted or required authorities
  • Redirecting API clients unexpectedly
  • High-cardinality or sensitive diagnostic fields
  • Different login failures enabling enumeration

Transfer

FastAPI exception handlers and NestJS exception filters provide equivalent contracts. Spring's pre-controller entry point and denied-handler boundary is framework-specific.

Continue with LAB-005.