spring-security-core: A Practical Security Guide

The spring-security-core artifact is the heart of the Spring Security framework, providing the authentication and authorization primitives that most Java applications build on. If you are pulling in org.springframework.security:spring-security-core, you are adopting the core engine of Spring Security. This guide covers what it does, a naming ambiguity worth knowing about, and the practical steps to keep it secure.

Two different artifacts share this name

Before anything else, clear up a common source of confusion. There are two well-known artifacts called spring-security-core:

• org.springframework.security:spring-security-core is the core module of the Spring Security framework itself, providing Authentication, GrantedAuthority, the SecurityContext, and the authorization engine.
• org.grails.plugins:spring-security-core is the Grails plugin that integrates Spring Security into the Grails framework. It depends on the Spring Security framework underneath.

They are versioned independently. The Grails plugin has its own release train (recent lines include 6.x and a 7.0 milestone series), while the framework module tracks Spring Security's own versions. Check which one your pom.xml or build.gradle actually references, because advisories and upgrade paths differ. When in doubt, inspect the coordinates:

<!-- The Spring Security framework core module -->
<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-core</artifactId>
</dependency>

What spring-security-core gives you

The framework core provides the building blocks the rest of Spring Security assembles:

• Authentication abstractions — the Authentication object, AuthenticationManager, and AuthenticationProvider interfaces.
• Authorization — GrantedAuthority, method-level security annotations, and the access decision machinery.
• The SecurityContext that holds the current principal, typically bound to the thread of the request being served.
• Password encoding through the PasswordEncoder abstraction.

You rarely use the core module alone. spring-security-web adds the servlet filter chain, and spring-security-config adds the configuration DSL, but the core is what they depend on.

Keep your version current

The single most important security practice for any framework dependency is staying on a supported, patched version. Spring Security, like any widely used library, has security advisories published over its lifetime, and the maintainers backport fixes to supported branches. Running an end-of-life version means you stop receiving those fixes.

Before writing off an upgrade as risky, check the actual advisory. For any specific CVE affecting Spring Security, consult the official Spring Security advisories page and the National Vulnerability Database rather than trusting a secondhand summary. Do not act on a version-specific vulnerability claim you have not verified against a primary source.

An SCA tool such as Safeguard can flag when your spring-security-core version has a known advisory, including when it is pulled in transitively by another dependency you did not choose directly.

Configure it securely

Having the library is not the same as using it safely. A few patterns matter more than the rest.

Encode passwords with a strong, adaptive algorithm. Use BCryptPasswordEncoder (or Argon2) and never store plaintext or fast-hashed passwords.

@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();
}

Deny by default. Configure your authorization rules so that any endpoint not explicitly permitted requires authentication. A rule set that whitelists public paths and locks everything else is far safer than one that tries to blacklist the sensitive ones.

Do not disable CSRF protection blindly. Spring Security enables CSRF protection for state-changing requests by default. Turning it off because "it was easier" reopens a whole vulnerability class. If you are building a stateless token-authenticated API, understand why the risk profile differs before you change the default.

Enforce method security where it counts. Annotations like @PreAuthorize("hasRole('ADMIN')") put the authorization decision next to the code it protects, which is harder to accidentally bypass than a URL pattern rule far away in config.

Common mistakes

The recurring failures teams hit with Spring Security:

• Leaving debug or actuator endpoints exposed without authentication.
• Storing secrets and signing keys in source control instead of a secrets manager.
• Custom AuthenticationProvider implementations that return an authenticated token even on a failed check.
• Overriding the default security configuration wholesale and losing the safe defaults in the process.

The framework ships secure defaults. Most incidents come from disabling or overriding those defaults without understanding what they protected.

FAQ

Is spring-security-core the same as the Grails plugin?

No. org.springframework.security:spring-security-core is the Spring Security framework's core module, while org.grails.plugins:spring-security-core is a separate Grails plugin that integrates Spring Security into Grails. They version independently, so confirm which one your build references.

Do I need spring-security-core directly?

Usually it arrives transitively. If you add spring-boot-starter-security or spring-security-config, the core module comes along automatically. You reference it directly mainly when managing versions explicitly.

How do I know if my version has a vulnerability?

Check the official Spring Security advisories and the National Vulnerability Database for your exact version, or let an SCA scanner match it for you. Never act on an unverified version-specific claim.

What is the most important thing to get right?

Staying on a supported, patched version and preserving the framework's secure defaults, especially password encoding, deny-by-default authorization, and CSRF protection. Most real incidents trace back to disabled defaults rather than framework bugs.