☕ Spring Boot and Spring Security — Practical Guide

Intro: Spring Security guidance on the internet ranges from very old XML-based examples to modern Boot-first configuration, and teams often carry both at the same time. This page keeps the durable architectural ideas—authentication, authorization, filter chains, ACL-style object protection, session security, HTTPS, and provider integration—while translating them into a modern Spring Boot / Spring Security review model.

What this page includes

• the Spring Security request path that reviewers should understand first;
• where Spring Boot teams usually misconfigure security in 2026;
• short starter examples for SecurityFilterChain, method security, and actuator isolation;
• review questions for route, method, session, and admin-plane security.

Start with the mental model, not the annotation

Spring-based teams often over-focus on a specific annotation and under-focus on where security is actually enforced.

In practice, four layers matter most:

1. request matching and filter-chain selection;
2. authentication establishment;
3. authorization on routes and business methods;
4. operational endpoints, sessions, and tokens that sit beside the main business flow.

If a team understands only @PreAuthorize or only route matchers, they often miss object-level or admin-plane drift.

A simple Spring Security architecture view

Durable concepts that still matter

Authentication and authorization are separate problems

The old Spring Security material gets this right and it still matters:

• authentication proves who the principal is;
• authorization decides what the principal may do.

A service can authenticate perfectly and still fail badly on:

• object ownership checks;
• tenant scoping;
• admin/support function isolation;
• background-task privilege separation.

The filter chain is not an implementation detail you can ignore

At a reviewer level, you do not need to memorize every filter. You do need to understand that Spring Security inserts security through a chain where authentication, security context handling, exploit protections, logout/session behavior, and authorization happen in a deliberate order.

That is why matcher scope, multiple SecurityFilterChain beans, and custom filters can either produce clean separation or subtle bypasses.

Method security is not optional when route security is too coarse

Route checks are often enough for basic access control, but many real applications need server-side checks inside business logic:

• ownership of a document, invoice, report, tenant object, or support action;
• role plus resource-state checks;
• privileged transitions that should never be controlled by UI alone.

When reviewers see only controller-level restrictions and no method/object-level enforcement, that should trigger a deeper authorization review.

Common 2026 Spring Boot / Spring Security failure patterns

1) Custom SecurityFilterChain breaks assumptions elsewhere

A team adds a custom chain for login or APIs and assumes Boot will still secure the rest “automatically.”

Reviewers should verify:

• what each chain matches;
• whether there is a fallback chain;
• whether actuator endpoints are intentionally covered;
• whether browser and API traffic are separated cleanly.

1.5) Spring Boot security defaults are helpful, but only until custom configuration appears

Boot gives teams a useful starting point, especially around actuator security, but reviewers should verify exactly what happens once a team introduces one or more custom SecurityFilterChain beans. Many “we thought Boot handled that” mistakes appear right at this boundary.

2) Actuator and management endpoints are exposed casually

Operational endpoints are extremely useful and frequently dangerous when exposed broadly.

Reviewers should ask:

• which actuator endpoints are exposed over HTTP;
• whether management traffic is separated by port, path, role, firewall, or network policy;
• whether /health is the only public endpoint or whether additional exposure was added for convenience;
• whether POST/PUT/DELETE management operations are compatible with CSRF posture and intended clients.

3) Route rules exist, but object-level authorization is weak

Look for:

• controllers checking only “is authenticated” or broad roles;
• repository or service calls keyed by user-supplied IDs without ownership checks;
• support/admin capabilities sharing normal business service methods;
• export/report/download paths that bypass normal domain authz.

4) Session, remember-me, and logout are treated as UX features only

For browser-backed apps, review:

• session fixation resistance and rotation on login;
• session invalidation on logout and privilege change;
• concurrent session policy where relevant;
• remember-me usage on privileged/admin paths.

5) Security provider integrations are added without lifecycle review

Review authentication provider integrations such as:

• LDAP / Active Directory;
• OAuth2 / OIDC login;
• JWT resource server mode;
• X.509 or other pre-authenticated flows.

High-value questions:

• who owns trust in the provider configuration;
• how role/authority mapping is normalized;
• what happens during logout, revocation, or key rotation;
• whether fallback or local accounts create a shadow-admin path.

Practical code patterns

Minimal Boot / SecurityFilterChain baseline

See: Spring Boot SecurityFilterChain and method-security snippet

What it should demonstrate:

• explicit SecurityFilterChain bean;
• CSRF posture chosen intentionally;
• stateless API defaults where appropriate;
• method security enabled for deeper authorization.

Separate actuator security chain

See: Spring Boot actuator security-chain snippet

What it should demonstrate:

• dedicated endpoint matcher for actuator routes;
• explicit role requirement for operational endpoints;
• separation from the rest of the application security rules.

Fast review map for Spring services

Browser-backed MVC applications

Prioritize:

• CSRF posture;
• session lifecycle;
• secure cookie configuration;
• remember-me usage;
• template rendering and admin-plane isolation.

REST APIs and resource servers

Prioritize:

• token validation and issuer/audience handling;
• method-level authorization on domain operations;
• error handling that does not leak stack or internal authority mapping;
• management endpoint exposure;
• outbound client trust and SSRF-prone integrations.

Internal enterprise services

Prioritize:

• directory or SSO provider trust boundaries;
• service-to-service auth and secret/certificate rotation;
• fallback users and test credentials;
• actuator, metrics, and debug feature exposure inside “trusted” networks.

Review questions engineers can use directly

• What does each SecurityFilterChain actually match, and what remains unmatched?
• Is authorization enforced only on controllers, or also in service methods and object ownership checks?
• Which actuator endpoints are exposed, to whom, and on what network path?
• Does logout invalidate sessions/cookies/tokens in the way the product team assumes?
• If an admin or support feature exists, how is it separated from normal business logic and telemetry?
• Are OAuth2/OIDC/JWT claims mapped into authorities in a documented and testable way?
• Where could a user change an ID or tenant key and reach another object without a second server-side decision?

Release blockers to treat seriously

A Spring service should usually not ship if:

• a custom SecurityFilterChain exists without clear matcher scoping or fallback behavior;
• actuator endpoints are exposed beyond the intended operations audience;
• object-level authorization is absent from service/domain flows that use user-controlled IDs;
• admin or support endpoints rely only on UI separation;
• login/session/logout assumptions are not tested against privilege change, reuse, and revocation;
• provider integrations introduce undeclared fallback identities or weak default credentials.

Read next

• Spring, ASP.NET, and Go Service Security Review Guide
• Web Application Security Review and Architecture Playbook
• Identity and Platform Access
• Browser Security Foundations: CSP, CORS, Cookies, and Sessions

Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.