Spring Security

Spring Security is a framework for authentication, authorization, and protection against common attacks in Spring applications.

It provides robust, configurable security with secure defaults and deep Spring integration.

Authentication verifies identity; authorization determines allowed actions.

The currently authenticated user/system identity.

A permission/role representation attached to authenticated principal.

Holds authentication information for current execution context.

Utility class providing access to SecurityContext (thread-bound by default).

Represents authentication request or authenticated principal token.

Core interface describing user credentials and authorities.

Service loading UserDetails by username (or identifier).

Strategy for hashing/verifying passwords.

If leaked, plain-text passwords immediately compromise all accounts.

BCrypt is commonly recommended for password hashing.

Adaptive one-way password hashing algorithm with configurable strength.

Main API that authenticates Authentication requests.

Component that performs actual authentication logic for specific mechanism.

Provider using UserDetailsService + PasswordEncoder for username/password auth.

Defines ordered security filters and HTTP authorization rules.

Security behavior depends on correct sequence of authentication/authorization filters.

Processes username/password login submissions.

HTTP auth scheme sending credentials in Authorization header (use only with TLS).

Browser-oriented authentication via HTML login page and session.

Fluent API for configuring web security rules.

Configures CSRF protection settings.

Attack forcing authenticated browser to send unintended state-changing requests.

Often disabled for pure stateless APIs not using browser cookies for auth (context-dependent).

Browser security model controlling cross-origin requests.

CORS controls origin access; CSRF protects against forged authenticated actions.

Server stores auth state in HTTP session after login.

Each request carries credentials/token; server does not store session auth state.

JSON Web Token carrying signed claims for stateless auth.

No, standard JWS tokens are signed, not encrypted.

Authority convention often prefixed with ROLE_.

hasRole("ADMIN") checks ROLE_ADMIN; hasAuthority checks exact authority string.

Allows unrestricted access to matched endpoints.

Requires any authenticated user.

Blocks all access to matched endpoints.

Allows only unauthenticated users (framework anonymous principal context).

Invalidates auth/session and clears context/cookies as configured.

Mechanism to persist login across browser restarts using secure tokens/cookies.

Use cautiously with strict controls or avoid for sensitive domains.

Spring Security can generate one automatically if form login enabled.

Component starting authentication flow when unauthenticated access occurs.

Handles 403 Forbidden when authenticated user lacks permissions.

Handles 401-like responses or auth initiation for unauthenticated requests.

Applying authorization rules at method level.

@PreAuthorize, @PostAuthorize, @Secured, @RolesAllowed.

Use annotation-based configuration (e.g., @EnableMethodSecurity).

Evaluates expression before method execution.

Evaluates authorization after method returns.

Minimizes blast radius of compromised accounts.

Start restrictive, explicitly open only required endpoints/actions.

Permitting broad paths accidentally (e.g., overly wide matchers).

Disabling CSRF/CORS without understanding threat model.

Protects credentials/tokens from interception.

Ensures cookies sent only over HTTPS.

Prevents JavaScript access to cookie values.

Helps mitigate cross-site request behaviors.

HTTPS, strong password hashing, narrow authorization rules, validated tokens.

Use framework defaults first, then customize with explicit threat-driven decisions.

Rule that selects which requests a security rule/filter chain applies to.

Different security rules for different endpoint groups (e.g., API vs actuator).

First matching chain handles request (ordering matters).

User-defined filter extracting credentials/tokens and creating Authentication requests.

Before username/password auth filter (exact placement depends on design).

Convenience base filter ensuring single execution per request dispatch path.

Context loaded/saved per request depending on session/stateless configuration.

Controls whether security creates/uses HTTP sessions.

Do not create/use HTTP session for SecurityContext.

Stores original request for post-login redirection in browser flows.

Usually disabled for pure API use cases.

Storage strategy for CSRF tokens (session/cookie-based variants).

Stores CSRF token in cookie (commonly for browser clients).

OPTIONS request browser sends to validate cross-origin permissions.

Blocked preflight prevents legitimate browser API calls.

Customize entry points and access denied behavior.

Integrate LDAP, external IDP, OTP, or domain-specific credential checks.

Validate locked/disabled/expired accounts before success.

Rate limits, lockouts/backoff, CAPTCHA/risk signals.

Requiring additional verification factors beyond password.

Yes, via custom/auth provider orchestration and external identity integrations.

Re-encode old hashes with stronger settings at login.

Supports multiple hash formats and gradual migration.

Transforming external claims/roles into internal GrantedAuthorities.

Defines implied roles (e.g., ADMIN implies USER).

Expression language evaluating authorization rules dynamically.

@PreAuthorize("hasRole('ADMIN') or #id = authentication.name")=

Injects current principal into controller method parameter.

Auth context may be lost across async threads if not propagated.

Use delegating executors/wrappers designed for security context transfer.

Fine-grained object-level permission model (advanced use case).

High rule cardinality and performance/management overhead.

Authorization framework allowing delegated access via tokens.

Identity layer on top of OAuth2 providing authentication and user identity claims.

Core actors in delegated authorization flow.

Server-side exchange of auth code for tokens, common for web apps.

Machine-to-machine flow without end-user login.

Longer-lived credential used to obtain new access tokens.

Runtime validation of opaque token with authorization server.

Signature verification, issuer/audience checks, expiration/not-before checks.

Ensures token is intended for your API/resource.

Ensures token comes from trusted authority.

Changing signing keys periodically while maintaining validation continuity.

Endpoint publishing public keys used to verify JWT signatures.

Component validating bearer tokens for protected APIs.

App acting as OAuth2 client for login or delegated calls.

Granting permissions based on token scopes (e.g., read:orders).

Roles are app/domain-centric; scopes are OAuth delegated permission strings.

Token without self-contained claims requiring introspection.

JWT enables local validation; opaque can simplify revocation/control centrally.

Stateless tokens remain valid until expiry unless additional revocation strategy used.

Short TTL, deny-lists, token versioning, introspection-based checks.

Automatic HTTP headers for browser hardening (HSTS, X-Content-Type-Options, etc.).

Mitigates XSS by restricting script/resource sources.

X-Frame-Options or CSP frame-ancestors directives.

Forces HTTPS usage via Strict-Transport-Security header.

Stuffing business authorization logic directly into controllers.

Method/domain-level policies with clear reusable authorization services.

Improves maintainability, clarity, and auditability.

Single-use short-lived tokens + strong verification + audit logging.

Leaking whether account exists via error messages/timing.

Generic responses and consistent processing paths.

Endpoint authorization matrix, method security, token validation, failure paths.

MockMvc/WebTestClient with authenticated/unauthenticated scenarios.

Security failures usually emerge in denied/invalid/edge conditions.

Audit auth events, denied access, anomaly rates, token failures.

Raw passwords, secrets, private keys, full sensitive tokens.

Log minimal token fingerprint/claims, never full bearer token.

Team can explain every permit rule and authentication path in production.

Threat-model-driven configuration with least privilege and strong tests.

Authenticate/authorize every request and avoid implicit network trust.

Layered controls: gateway, app security, method rules, data policies, auditing.

Central policy logic with distributed enforcement points.

Attribute-based access control using subject/resource/context attributes.

RBAC simpler; ABAC more expressive but more complex to govern.

Domain permission checks near business operations, not only URL-level.

Service misuses higher privilege on behalf of less privileged caller.

Propagate caller identity/claims and enforce downstream authorization.

Exchanging one token for another scoped token for downstream service.

Limits exposure window if token is leaked.

Protect signing keys in HSM/KMS and rotate with auditable process.

Asymmetric improves key distribution separation; symmetric simpler but riskier sharing.

Mutual TLS provides strong service identity at transport layer.

No, it complements but does not replace fine-grained authZ logic.

Require stronger auth factors for sensitive operations.

Adaptive controls based on context/anomaly signals.

Changing session id after authentication to prevent hijacking.

Limit active sessions per user/account.

Revoking access across many services/tokens consistently.

Server-to-server logout notification to relying parties.

Stale permissions after role/policy changes.

Short TTL, event-driven invalidation, versioned policies.

Excessive per-call SpEL/policy checks on hot paths.

Cache stable decisions carefully and move complex checks to dedicated policy services.

Tamper-evident, append-only, restricted access, retention policy alignment.

Industry/location-specific compliance requirements (e.g., finance/health/privacy laws).

Actionable logs, alerting, runbooks, token/key revocation procedures.

Inject auth failures/key rotation issues to validate resilience.

Fail-closed denies on uncertainty; fail-open allows continuity with risk.

Authentication/authorization decision points for protected resources.

Timing/error differences revealing credential/account information.

Constant-time comparisons and normalized error processing.

Server-side secret combined with password hashing for extra protection.

Regularly rotate credentials/keys with tested rollback and dual-key windows.

Secure issuance/rotation of service credentials/certificates.

Standardized workload identities for zero-trust environments.

Gateway handles coarse controls; app enforces domain/resource-level authorization.

Tailored token handling and reduced exposure for browser/mobile clients.

Binding token use to proof-of-possession key to reduce replay risk.

Nonce/timestamps, short TTL tokens, PoP mechanisms, idempotency controls.

SameSite helps but may not replace CSRF tokens in all browser/workflow cases.

Org-level baseline configs/starters preventing insecure deviations.

Over-permissive wildcard rules added “temporarily” and never removed.

Incremental hardening with automated authorization tests and telemetry.

TLS, strong auth, least privilege, auditing, rotation, alerting, recovery drills.

Keep policies explicit, versioned, reviewed, and test-enforced.

They can explain every access rule, token trust boundary, and failure mode.

Treat security as product architecture, not middleware checkbox.

Continuously monitor, test, and rotate—security posture is never static.

Secure-by-default, least-privilege, observable, and resilient under attack/failure.