Security is one of the most important parts of any backend application.

Imagine you’ve built a Java application where users can:

• Create accounts
• Log in
• View their profile
• Update personal information
• Place orders
• Access an admin dashboard

You probably don’t want every user to access every part of the application.

For example:

Regular User → User Dashboard ✓
Regular User → Admin Dashboard ✗

This is where Spring Security comes in.

Spring Security is a powerful security framework commonly used with Spring and Spring Boot applications. It provides tools for authentication, authorization, password protection, request security, and more.

In this beginner-friendly guide, we’ll learn how to secure a Java application using Spring Security and understand the concepts behind it.

We’ll cover:

• What Spring Security is
• Authentication vs authorization
• How Spring Security works
• Adding Spring Security to Spring Boot
• Securing endpoints
• Users and roles
• Password hashing
• HTTP Basic authentication
• Form login
• JWT authentication
• Method-level security
• CSRF
• CORS
• Exception handling
• Security best practices

Let’s get started.

---

What Is Spring Security?

Spring Security is a framework that provides authentication and authorization features for Java applications built with Spring.

It helps protect your application from unauthorized access.

A simplified flow looks like this:

Client
  ↓
HTTP Request
  ↓
Spring Security
  ↓
Authentication
  ↓
Authorization
  ↓
Controller
  ↓
Response

Spring Security can determine:

Who is this user?

and:

Is this user allowed to access this resource?

---

Authentication vs Authorization

These two terms are extremely important.

Authentication

Authentication answers:

“Who are you?”

For example, a user logs in with:

Email
Password

The application verifies the credentials.

Login Request
     ↓
Check Credentials
     ↓
User Verified
     ↓
Authenticated

---

Authorization

Authorization answers:

“What are you allowed to do?”

For example:

Admin
 ↓
Can manage users ✓


Regular User
 ↓
Cannot manage users ✗

So remember:

Authentication → Who are you?

Authorization → What can you access?

---

Why Do We Need Spring Security?

You could technically write your own authentication and authorization system.

But doing security correctly is difficult.

You need to think about:

• Password storage
• Session management
• Authentication
• Authorization
• CSRF protection
• CORS
• Security headers
• Brute-force protection
• Token handling
• Access control

A security framework provides tested building blocks for these common problems.

Spring Security integrates deeply with the Spring ecosystem and lets you configure security rules without implementing everything from scratch.

---

Adding Spring Security to a Spring Boot Project

If you’re using Maven, you can add the Spring Security starter:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

Once Spring Security is added, Spring Boot automatically enables security-related configuration.

For a new application, this can change how your endpoints behave because requests may require authentication.

---

What Happens When Spring Security Is Added?

Suppose you already have:

@RestController
public class ProductController {

    @GetMapping("/products")
    public String products() {
        return "Product List";
    }
}

Before security, a client may be able to access:

GET /products

After adding Spring Security, the endpoint can require authentication depending on your security configuration.

Conceptually:

Request
  ↓
Security Filter Chain
  ↓
Authenticated?
  ├── No → Authentication Required
  │
  └── Yes → Continue
             ↓
         Controller

---

The Security Filter Chain

One of the most important Spring Security concepts is the Security Filter Chain.

Incoming HTTP requests pass through a series of security filters before reaching your controller.

Conceptually:

HTTP Request
     ↓
Security Filters
     ↓
Authentication
     ↓
Authorization
     ↓
Controller

The filters can handle things such as:

• Authentication
• Authorization
• CSRF protection
• Security context
• Request processing

You don’t normally need to understand every filter to start using Spring Security, but understanding the filter-chain concept is important.

---

Creating a Security Configuration

Modern Spring Security applications commonly configure security using a SecurityFilterChain bean.

For example:

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain securityFilterChain(
            HttpSecurity http
    ) throws Exception {

        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers(
                    "/public/**"
                ).permitAll()
                .anyRequest().authenticated()
            );

        return http.build();
    }
}

This configuration means:

/public/**
     ↓
Anyone can access


Everything else
     ↓
Authentication required

---

Understanding HttpSecurity

The HttpSecurity object lets you configure how HTTP requests should be secured.

For example:

http
    .authorizeHttpRequests(auth -> auth
        .requestMatchers("/public/**")
        .permitAll()
        .anyRequest()
        .authenticated()
    );

You’re essentially defining rules such as:

Public endpoints → Allow everyone
Protected endpoints → Require authentication

---

Protecting Specific Endpoints

Suppose you have:

/api/products
/api/orders
/api/admin

You might want:

/api/products → Public
/api/orders   → Logged-in users
/api/admin    → Admin only

You can express rules like:

http.authorizeHttpRequests(auth -> auth

    .requestMatchers(
        "/api/products"
    ).permitAll()

    .requestMatchers(
        "/api/orders/**"
    ).authenticated()

    .requestMatchers(
        "/api/admin/**"
    ).hasRole("ADMIN")

    .anyRequest()
    .authenticated()
);

Now different parts of the application have different access requirements.

---

What Is a Role?

A role represents a category of permissions.

For example:

ADMIN
USER
MANAGER

You might have:

ADMIN
 ↓
Manage users
Delete products
View reports


USER
 ↓
View products
Create orders
View own orders

Spring Security can use roles to control access.

For example:

.requestMatchers("/admin/**")
.hasRole("ADMIN")

This means only users with the ADMIN role can access those endpoints.

---

What Is a Permission or Authority?

Roles are commonly used for broad access categories.

Authorities can represent more specific permissions.

For example:

PRODUCT_READ
PRODUCT_CREATE
PRODUCT_UPDATE
PRODUCT_DELETE

You could then check:

.hasAuthority("PRODUCT_DELETE")

This gives you finer-grained access control.

---

Creating a User

For a simple example, you can configure an in-memory user.

@Bean
public UserDetailsService users(
        PasswordEncoder passwordEncoder
) {

    UserDetails user =
        User.withUsername("alex")
            .password(
                passwordEncoder.encode(
                    "strong-password"
                )
            )
            .roles("USER")
            .build();

    return new InMemoryUserDetailsManager(user);
}

This is useful for learning and testing.

Real applications usually store user accounts in a database.

---

Never Store Plain-Text Passwords

This is one of the most important security rules.

Never store passwords like:

alex123
password123
welcome123

directly in your database.

Instead, store a secure password hash.

For example:

User Password
      ↓
Password Hashing
      ↓
Stored Hash

When the user logs in:

Entered Password
       ↓
Hash Verification
       ↓
Stored Hash
       ↓
Match?

The original password should not need to be stored.

---

PasswordEncoder

Spring Security provides PasswordEncoder for password hashing and verification.

For example:

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

You can then hash a password:

String hash =
    passwordEncoder.encode(
        "strong-password"
    );

The resulting hash is what should be stored rather than the original password.

---

Why Hash Passwords?

Imagine your database gets compromised.

If passwords were stored as plain text:

alex → secret123
oliver → mypassword
sophia → welcome123

the attacker could immediately see them.

With password hashing:

alex → $2a$...
oliver → $2a$...
sophia → $2a$...

the original passwords aren’t directly stored.

Password hashing is therefore a fundamental security practice.

---

What Is BCrypt?

BCrypt is a password hashing algorithm commonly used for password storage.

It is designed to be computationally expensive enough to make brute-force attacks harder.

For example:

new BCryptPasswordEncoder()

can be used as a password encoder.

The important point is:

Don’t invent your own password hashing algorithm.

Use established password-hashing mechanisms provided by trusted security libraries.

---

Authentication with HTTP Basic

One simple authentication mechanism is HTTP Basic Authentication.

You can enable it for an application:

http
    .httpBasic(Customizer.withDefaults());

The client sends credentials with the request.

Conceptually:

Client
  ↓
Username + Password
  ↓
Spring Security
  ↓
Authentication

HTTP Basic can be useful for simple APIs, internal tools, development, or certain controlled environments.

For production APIs, you need to consider transport security and your broader authentication architecture.

---

Form Login

For traditional web applications, Spring Security can also provide form-based login.

You can enable it with:

http
    .formLogin(Customizer.withDefaults());

The flow becomes:

User
 ↓
Login Page
 ↓
Username + Password
 ↓
Spring Security
 ↓
Authenticated Session

This is commonly associated with server-rendered web applications.

---

Session-Based Authentication

With session-based authentication, the server maintains authentication state.

A simplified flow:

Login
  ↓
Server Authenticates User
  ↓
Session Created
  ↓
Session ID Sent to Client
  ↓
Client Sends Session ID
  ↓
Server Recognizes User

This is a common model for traditional web applications.

---

What Is JWT Authentication?

For many REST APIs, you may encounter JWT (JSON Web Token) based authentication.

A simplified flow looks like:

User
 ↓
Login
 ↓
Authentication Server
 ↓
JWT Token
 ↓
Client
 ↓
Authorization Header
 ↓
API

A request might include:

Authorization: Bearer <token>

The server validates the token and determines whether the request is authenticated.

---

JWT Does Not Automatically Mean More Secure

JWT is popular, but it’s important to understand that using JWT doesn’t automatically make an application secure.

You still need to handle:

• Token expiration
• Token storage
• Token validation
• Key management
• Token revocation strategy
• Refresh tokens
• Transport security

Choose authentication based on your application’s architecture rather than simply because JWT is popular.

---

Securing Methods

Spring Security can also protect individual methods.

For example:

@PreAuthorize("hasRole('ADMIN')")
public void deleteUser(Long id) {
    // Delete user
}

You can enable method security with:

@EnableMethodSecurity

This gives you another layer of authorization.

Instead of putting every rule only at the HTTP level, you can also protect specific service methods.

---

Securing Service Logic

For example:

@Service
public class UserService {

    @PreAuthorize("hasRole('ADMIN')")
    public void deleteUser(Long id) {

        // Delete user
    }
}

Now the method itself requires the appropriate role.

This can be useful when the business operation should always be protected regardless of which controller calls it.

---

What Is CSRF?

CSRF stands for Cross-Site Request Forgery.

It is an attack where a malicious site attempts to make a user’s browser send an unwanted authenticated request to another application.

CSRF protection is especially important for applications using browser-based authentication such as cookies and sessions.

For example:

User logged in
      ↓
Session Cookie
      ↓
Malicious Website
      ↓
Attempts unwanted request

Spring Security provides CSRF protection mechanisms.

---

Should You Disable CSRF?

You may see API configurations like:

http.csrf(csrf -> csrf.disable());

But don’t blindly copy this into every application.

Whether CSRF protection is appropriate depends on how authentication is implemented and how the application is used.

For a stateless API that does not use browser cookies for authentication, the CSRF threat model can be different.

For a traditional browser application using session cookies, CSRF protection is often important.

Security configuration should always match your actual architecture.

---

What Is CORS?

CORS stands for Cross-Origin Resource Sharing.

It controls which origins are allowed to make browser-based requests to your API.

Imagine your frontend runs at:

https://app.example.com

while your API runs at:

https://api.example.com

These are different origins.

Your API may need to explicitly allow the frontend origin.

A simple configuration might look like:

http.cors(
    Customizer.withDefaults()
);

You then configure which origins, methods, and headers are allowed.

---

CORS Is Not Authentication

This is an important distinction.

CORS controls browser cross-origin behavior.

It does not replace:

• Authentication
• Authorization
• Access control

For example:

CORS
 ↓
Controls browser access


Authentication
 ↓
Identifies the user


Authorization
 ↓
Controls permissions

They solve different problems.

---

Handling Access Denied Errors

Sometimes a user is authenticated but doesn’t have enough permissions.

For example:

User → /admin
       ↓
Authenticated ✓
       ↓
ADMIN role? ✗
       ↓
403 Forbidden

A 403 Forbidden response generally means the server understood the request but won’t allow access based on the user’s permissions.

---

401 vs 403

These status codes are often confused.

401 Unauthorized

Typically means authentication is required or failed.

Who are you?
     ↓
Not authenticated
     ↓
401

403 Forbidden

Typically means the user is authenticated but doesn’t have permission.

Who are you?
     ↓
Authenticated
     ↓
Allowed?
     ↓
No
     ↓
403

Remember:

401 → Authentication problem
403 → Authorization problem

---

A Simple Secure API Architecture

A typical Spring Boot application might look like:

Client
  ↓
Spring Security
  ↓
Authentication
  ↓
Authorization
  ↓
Controller
  ↓
Service
  ↓
Repository
  ↓
Database

Security sits around the application’s request-processing flow.

---

Example Security Configuration

Here’s a simplified example:

@Configuration
@EnableWebSecurity
@EnableMethodSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain
    securityFilterChain(
            HttpSecurity http
    ) throws Exception {

        http
            .authorizeHttpRequests(auth -> auth

                .requestMatchers(
                    "/api/public/**"
                ).permitAll()

                .requestMatchers(
                    "/api/admin/**"
                ).hasRole("ADMIN")

                .requestMatchers(
                    "/api/user/**"
                ).hasAnyRole(
                    "USER",
                    "ADMIN"
                )

                .anyRequest()
                .authenticated()
            )
            .httpBasic(
                Customizer.withDefaults()
            );

        return http.build();
    }
}

This is a simplified learning example. Real applications may use session authentication, OAuth2, JWT, or another authentication architecture depending on their requirements.

---

Securing Password Reset

Password reset functionality deserves special attention.

A secure reset flow typically looks like:

User Requests Reset
       ↓
Generate Random Token
       ↓
Send Reset Link
       ↓
User Opens Link
       ↓
Verify Token
       ↓
Set New Password
       ↓
Invalidate Token

Reset tokens should be:

• Random
• Short-lived
• Single-use
• Stored securely

Avoid creating predictable reset tokens.

---

Account Lockout and Rate Limiting

Authentication endpoints can be targeted by brute-force attacks.

For example:

Login Attempt 1
Login Attempt 2
Login Attempt 3
...
Login Attempt 1000

Your application should consider protections such as:

• Rate limiting
• Temporary account lockout
• Monitoring
• Alerts
• Strong password policies
• Multi-factor authentication

These controls help reduce automated credential attacks.

---

Secure Your Configuration

Never hard-code secrets in your source code.

Avoid:

String password = "my-database-password";

Instead, use environment variables or a proper secrets-management system.

For example:

DATABASE_USERNAME
DATABASE_PASSWORD
JWT_SECRET

The exact approach depends on your deployment environment.

---

Use HTTPS

Authentication credentials and sensitive data should be transmitted over HTTPS.

Without encryption, sensitive information can potentially be exposed during network transmission.

Conceptually:

HTTP
 ↓
Data can be exposed


HTTPS
 ↓
Encrypted connection

For production applications, HTTPS should be considered a baseline security requirement.

---

Security Headers

Spring Security can help configure security-related HTTP headers.

Examples include protections involving:

• Clickjacking
• Content type sniffing
• Browser security behavior

You should understand what each header does rather than blindly enabling or disabling headers.

---

Keep Dependencies Updated

Security vulnerabilities can sometimes be discovered in application dependencies.

Regularly update:

• Spring Boot
• Spring Security
• Database drivers
• Libraries
• Authentication components

Also review security advisories relevant to your dependencies.

Keeping dependencies current is an important part of application security.

---

Common Spring Security Mistakes

1. Storing Plain-Text Passwords

Never store user passwords directly.

Use a strong password hashing mechanism.

2. Hard-Coding Secrets

Don’t put database passwords, API keys, or token signing secrets directly into source code.

3. Giving Everyone ADMIN Access

Use the principle of least privilege.

Users should have only the permissions they actually need.

4. Disabling Security Features Without Understanding Them

Don’t copy:

csrf.disable()

or other configuration blindly.

Understand the threat model first.

5. Ignoring HTTPS

Authentication without secure transport can expose credentials or tokens.

6. Trusting Client-Supplied Roles

Don’t simply trust a role sent by the client.

Permissions must come from a trusted authentication/authorization system.

7. Returning Sensitive Error Details

Avoid exposing internal implementation details, database errors, stack traces, or secrets in API responses.

---

Principle of Least Privilege

One of the most useful security principles is:

Give users only the permissions they need.

For example:

Customer
 ↓
View own orders


Support Agent
 ↓
View customer information


Admin
 ↓
Manage users and system settings

Don’t give every authenticated user full access.

This limits the potential damage if an account is compromised.

---

Authentication Flow in a Real Application

A typical login flow might look like:

                Client
                  ↓
             Login Request
                  ↓
          Spring Security
                  ↓
          Authentication
                  ↓
          User Database
                  ↓
        Credentials Verified
                  ↓
          Authenticated User
                  ↓
          Session / Token
                  ↓
           Protected API

This is the basic idea behind secure application authentication.

---

Spring Security Learning Path

If you’re new to Spring Security, don’t try to learn everything immediately.

Follow this order:

Spring Boot Basics
       ↓
HTTP Basics
       ↓
Authentication
       ↓
Authorization
       ↓
SecurityFilterChain
       ↓
Password Hashing
       ↓
Roles & Authorities
       ↓
Sessions
       ↓
CSRF & CORS
       ↓
JWT / OAuth2
       ↓
Method Security
       ↓
Testing & Security Hardening

Build a small project while learning.

For example:

Project
  ↓
User Registration
  ↓
Login
  ↓
Password Hashing
  ↓
Protected APIs
  ↓
USER Role
  ↓
ADMIN Role
  ↓
JWT or Session Authentication

This gives you practical experience with the concepts.

---

Final Thoughts

Spring Security provides a powerful foundation for securing Java and Spring Boot applications.

The most important concepts to understand are:

• Authentication → Who are you?
• Authorization → What are you allowed to access?
• Security Filter Chain → Processes requests through security filters
• Password Hashing → Protects stored passwords
• Roles & Authorities → Control permissions
• CSRF → Protects applicable browser-based authentication flows
• CORS → Controls browser cross-origin requests
• HTTPS → Protects data in transit
• Least Privilege → Give users only necessary permissions

A secure application isn’t created by adding one annotation or copying one configuration class.

Security is a combination of authentication, authorization, secure password handling, safe configuration, dependency management, transport security, input validation, monitoring, and good application design.

Start with a simple Spring Boot application, protect a few endpoints, add user roles, implement secure password storage, and then move into more advanced authentication methods such as JWT and OAuth2.

The goal isn’t just to make an API that works.

The goal is to make an API that works safely.