• Ngày xuất bản:

Spring Boot Security là gì? Khác gì với Spring Security?

spring boot security - itviec blog

Trong phát triển ứng dụng web, bảo mật là yếu tố sống còn. Với các ứng dụng xây dựng trên nền tảng Spring, Spring Boot Security chính là “tấm khiên” mạnh mẽ và linh hoạt để chống lại các mối đe dọa an ninh mạng. Bài viết này sẽ hướng dẫn bạn cách tích hợp và sử dụng Spring Boot Security một cách hiệu quả, từ các bước xác thực và phân quyền cơ bản đến những kỹ thuật nâng cao, giúp bạn bảo vệ ứng dụng của mình một cách toàn diện.

Đọc bài viết này để hiểu rõ:

  • Spring Boot Security có gì giống và khác với Spring Security?
  • Các khái niệm quan trọng của Spring Boot Security
  • Hướng dẫn cài đặt cấu hình và làm việc với Spring Boot security
  • Các chủ đề nâng cao và bảo mật toàn diện
  • Các phương pháp tốt nhất để sử dụng Spring Boot security

Spring Boot Security có gì khác với Spring Security?

Để hiểu rõ Spring Boot Security, trước tiên chúng ta cần phân biệt nó với “cha đẻ” của nó là Spring Security.

Spring Security là gì?

Spring Security là một framework mạnh mẽ và tùy biến cao, cung cấp các giải pháp toàn diện về xác thực (Authentication) và phân quyền (Authorization) cho các ứng dụng Java. Nó là một dự án riêng biệt trong hệ sinh thái Spring, có khả năng tích hợp với nhiều công nghệ khác nhau.

Tuy nhiên, sức mạnh của nó cũng đi kèm với sự phức tạp trong việc cấu hình ban đầu, đòi hỏi lập trình viên phải tự tay thiết lập rất nhiều thành phần.

Đọc chi tiết: Spring security: Khám phá framework bảo mật hàng đầu cho ứng dụng Java

Spring Boot Security là gì?

Spring Boot Security không phải là một framework hoàn toàn mới. Chính xác hơn, nó là cách mà Spring Boot tích hợp và tự động cấu hình Spring Security. Khi bạn thêm spring-boot-starter-security vào dự án, Spring Boot sẽ tự động áp dụng một chuỗi các cấu hình bảo mật mặc định hợp lý (sensible defaults). Điều này giúp bạn có ngay một ứng dụng được bảo vệ mà không cần viết bất kỳ dòng code cấu hình nào.

Nói một cách đơn giản: Spring Boot Security = Spring Security + Tự động cấu hình.

Spring Boot Security có gì khác với Spring Security?

Bảng dưới đây tổng hợp các điểm khác nhau cơ bản giữa Spring Security vs Spring Boot Security:

Tiêu chíSpring Security (Truyền thống)Spring Boot Security
Cấu hìnhPhức tạp và thụ động hơn: Phải tự tạo các lớp cấu hình (ví dụ: kế thừa từ WebSecurityConfigurerAdapter trước đây), định nghĩa các Bean như PasswordEncoder, AuthenticationManager một cách thủ công.Đơn giản và tự động: Chỉ cần thêm starter, Spring Boot tự động cung cấp cấu hình bảo mật cơ bản. Mọi endpoint mặc định đều được bảo vệ. Cấu hình tùy chỉnh chỉ cần khi muốn thay đổi hành vi mặc định.
DependenciesPhải tự quản lý các dependency liên quan và đảm bảo tương thích phiên bản.Chỉ cần một dependency duy nhất: spring-boot-starter-security. Spring Boot sẽ lo phần còn lại.
Hành vi mặc địnhKhông có hành vi mặc định nào. Bạn phải tự định nghĩa mọi thứ từ đầu: trang đăng nhập, cách xử lý, các URL cần bảo vệ.Bảo mật ngay lập tức: Tự động tạo trang đăng nhập, bảo vệ tất cả các endpoint, bật các tính năng chống tấn công phổ biến (CSRF, XSS), tạo một user mặc định với mật khẩu ngẫu nhiên in ra ở console.
Triết lýCung cấp các công cụ để bạn xây dựng hệ thống bảo mật từ con số không.“Ưu tiên quy ước hơn cấu hình” (Convention over Configuration): Cung cấp một hệ thống bảo mật hoạt động ngay lập tức, bạn chỉ cần can thiệp khi có nhu cầu đặc biệt.

Spring Boot có các tính năng nào của Spring Security? 

Về bản chất, Spring Boot Security chính là Spring Security, nhưng được Spring Boot tự động cấu hình sẵn (auto-configuration). Thay vì phải thiết lập mọi thứ từ đầu, Spring Boot cung cấp các cài đặt bảo mật mặc định hợp lý, giúp ứng dụng của bạn an toàn ngay lập tức.

Nó sở hữu toàn bộ các tính năng mạnh mẽ của Spring Security, bao gồm:

  • Xác thực (Authentication): Hỗ trợ đa dạng các hình thức từ form đăng nhập, kết nối cơ sở dữ liệu, cho đến tích hợp với các nhà cung cấp OAuth2 như Google, Facebook.
  • Phân quyền (Authorization): Cho phép giới hạn quyền truy cập linh hoạt dựa trên vai trò người dùng (roles), đường dẫn (URL), hoặc thậm chí ở cấp độ phương thức (method-level).
  • Chống tấn công phổ biến: Tự động tích hợp sẵn cơ chế bảo vệ chống lại các lỗ hổng như CSRF (Cross-Site Request Forgery), Session Fixation, và Clickjacking.
  • Mã hóa mật khẩu: Bắt buộc sử dụng các thuật toán mã hóa mạnh và hiện đại như BCrypt để lưu trữ mật khẩu an toàn.

Tóm lại: Khi sử dụng Spring Boot Security, bạn nhận được toàn bộ sức mạnh của Spring Security nhưng với ít công sức cấu hình hơn rất nhiều, giúp đẩy nhanh tốc độ phát triển. 

Các khái niệm quan trọng của Spring Boot Security

Cơ chế tự động cấu hình (auto-configuration)

Khi bạn tích hợp Spring Boot Security vào dự án, bạn chỉ cần khai báo một dependency duy nhất là spring-boot-starter-security. Ngay lập tức, Spring Boot sẽ kích hoạt cơ chế tự động cấu hình (auto-configuration).

Cơ chế này sẽ:

  • Bảo vệ tất cả các endpoint: Mọi yêu cầu HTTP đến ứng dụng của bạn sẽ mặc định yêu cầu xác thực.
  • Tạo Form Đăng nhập: Tự động sinh ra một trang đăng nhập (/login) cho người dùng.
  • Kích hoạt Basic Authentication: Hỗ trợ xác thực qua HTTP Basic Auth cho các client không dùng trình duyệt.
  • Tạo một người dùng mặc định: Một user tên là user sẽ được tạo với một mật khẩu ngẫu nhiên duy nhất được in ra trong console lúc khởi động ứng dụng.
  • Bảo vệ chống lại các tấn công phổ biến: Các tính năng như CSRF (Cross-Site Request Forgery) được bật mặc định.

Tùy chỉnh Cấu hình Bảo mật

Để thay đổi các hành vi mặc định trên, chúng ta cần định nghĩa cấu hình của riêng mình. Có 2 cách để tùy chỉnh cấu hình bảo mật như sau:

  • Cách cũ (WebSecurityConfigurerAdapter): Trước đây, người dùng thường kế thừa lớp này và ghi đè các phương thức của nó. Cách này đã bị deprecated (không dùng nữa) từ Spring Security 5.7.0 và bạn nên tránh sử dụng.
  • Cách mới (SecurityFilterChain Bean): Đây là cách tiếp cận hiện đại và được khuyến khích. Bạn sẽ tạo một @Bean trả về một đối tượng SecurityFilterChain. Bên trong bean này, bạn sử dụng đối tượng HttpSecurity để xây dựng chuỗi quy tắc bảo mật của mình. Cách này linh hoạt và phù hợp với kiến trúc dựa trên component của Spring.

Xác thực trong bộ nhớ (In-memory Authentication)

Đây là cách đơn giản nhất để cung cấp thông tin người dùng cho mục đích phát triển hoặc cho các ứng dụng nhỏ. Thay vì kết nối với cơ sở dữ liệu, bạn định nghĩa thẳng danh sách người dùng, mật khẩu và vai trò của họ ngay trong mã nguồn.

Để thực hiện được cơ chế này, Spring Security dựa trên hai interface cốt lõi sau:

  • UserDetailsService: Là một interface cốt lõi trong Spring Security, có nhiệm vụ tải thông tin người dùng dựa trên username.
  • UserDetails: Là một interface khác, chứa các thông tin cần thiết của một người dùng (username, password, authorities – quyền hạn).

Mã hóa Mật khẩu (Password Encoding) 

Nguyên tắc vàng để bảo mật mật khẩu đó là: Không bao giờ lưu trữ mật khẩu dưới dạng văn bản thuần túy (plain text). Mật khẩu phải luôn được “băm” (hashed) bằng một thuật toán mạnh, một chiều.

Để hiện thực hóa nguyên tắc này, Spring Security cung cấp interface PasswordEncoder để xử lý việc mã hóa và so sánh mật khẩu.

Trong đó, BCryptPasswordEncoder là một trong những cài đặt phổ biến và an toàn nhất của PasswordEncoder. BCrypt là một thuật toán băm mật khẩu thích ứng, tự động tích hợp “salt” để chống lại các cuộc tấn công bảng cầu vồng (rainbow table attacks).

Xác thực (Authentication)

Trong Spring Boot Security, có nhiều phương thức xác thực khác nhau, mỗi loại phù hợp với các yêu cầu và kiến trúc ứng dụng web hiện đại. Dưới đây là một số phương thức phổ biến:

Form-Based Authentication (Xác thực qua Form)

Đây là phương thức đăng nhập username/mật khẩu kinh điển cho các ứng dụng web truyền thống. Phương thức này phù hợp nhất cho các ứng dụng web có quản lý session phía máy chủ.

Spring Boot Security cho phép bạn dễ dàng tùy chỉnh trang đăng nhập và kiểm soát logic sau khi người dùng đăng nhập thành công hoặc thất bại. 

JDBC-Based Authentication (Xác thực qua Database)

Đây là phương thức sử dụng thông tin người dùng được lưu trữ trong cơ sở dữ liệu để xác thực danh tính.

Trường hợp cần sử dụng:

  • Khi bạn cần quản lý người dùng một cách động, nghĩa là có khả năng thêm, sửa, xóa người dùng thông qua giao diện quản trị của ứng dụng.
  • Khi ứng dụng của bạn cần tích hợp với một hệ thống quản lý người dùng hiện có đã lưu trữ trong database.
  • Phù hợp cho hầu hết các ứng dụng web truyền thống hoặc ứng dụng cần một hệ thống quản lý người dùng tập trung.

Cách làm:

  • Cấu hình DataSource cho database.
  • Tạo UserDetailsService tùy chỉnh để truy vấn thông tin người dùng từ DB.
  • Sử dụng PasswordEncoder để mã hóa và so sánh mật khẩu.

JWT (JSON Web Tokens) Authentication (Xác thực bằng JWT)

Đây là phương thức xác thực phi trạng thái bằng cách truyền tải token chứa thông tin an toàn giữa client và server.

Cách này lý tưởng cho RESTful API, Microservices, Single Page Application (SPA), Mobile Apps (server không lưu session).

Cách làm:

  • Client đăng nhập, server trả về JWT.
  • Client gửi JWT trong header Authorization cho các request tiếp theo.
  • Server dùng bộ lọc để giải mã và xác thực JWT.

OAuth 2.0 & OpenID Connect (OIDC)

Phương thức này cho phép người dùng đăng nhập vào ứng dụng của bạn thông qua một nhà cung cấp thứ ba như Google, Facebook, hay GitHub (ví dụ: nút “Login with Google”). Cách này có lợi ích là tăng sự tiện lợi cho người dùng và giảm gánh nặng quản lý mật khẩu.

Cách làm: Thêm spring-boot-starter-oauth2-client và cấu hình Client ID, Client Secret trong application.properties.

So sánh xác thực trong Spring Security vs Spring Boot Security

Để có thể nhìn thấy rõ nhưng khác biệt trong cách triển khai xác thực giữa Spring Security và Spring Boot Security, ta có bảng sau:

Phương thức Xác thựcSpring Security (Truyền thống)Spring Boot Security (Khác biệt chính )
Form-BasedCấu hình thủ công toàn bộ: Phải tự định nghĩa tường minh mọi thứ như trang đăng nhập, URL xử lý, các handler…Tự động hóa: Cung cấp sẵn form đăng nhập và endpoint. Bạn chỉ cần viết code để tùy chỉnh lại hành vi mặc định.
JDBC-BasedCấu hình DataSource thủ công: Phải tự tạo bean DataSource và kết nối nó vào UserDetailsService.Tự động cấu hình DataSource: Chỉ cần khai báo trong file application.properties, Spring Boot tự động tạo bean và tích hợp.
JWTTích hợp thủ công: Logic cốt lõi giống nhau, nhưng việc đăng ký và tích hợp filter vào chuỗi bảo mật phức tạp hơn.Tích hợp dễ dàng hơn: Việc đăng ký filter tùy chỉnh đơn giản hơn nhờ cơ chế component scanning (@Component).
OAuth 2.0 / OIDCCực kỳ phức tạp: Yêu cầu cấu hình Java dài dòng với nhiều bean được định nghĩa thủ công (ClientRegistrationRepository,…)Cực kỳ đơn giản: Chỉ cần thêm starter và vài dòng cấu hình trong application.properties. Mọi thứ được tự động cấu hình.

Ủy quyền trong Spring Boot security

Ủy quyền (Authorization) trong Spring Boot Security là quá trình xác định người dùng đã được xác thực có quyền truy cập vào một tài nguyên cụ thể hay không. Các cách ủy quyền chính:

Ủy quyền dựa trên vai trò (Role-Based)

Đây là cách tiếp cận phổ biến nhất, trong đó quyền truy cập được cấp dựa trên vai trò của người dùng (ví dụ: ADMIN, USER, MANAGER).

Trong cấu hình HttpSecurity, bạn sử dụng các phương thức hasRole() (yêu cầu một vai trò cụ thể) và hasAnyRole() (yêu cầu một trong nhiều vai trò).

Dưới đây là 1 ví dụ về các triển khai ủy quyền Role-Based:

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests(authorize -> authorize
        // Chỉ người dùng có vai trò 'ADMIN' mới được truy cập các URL bắt đầu bằng /admin/
        .requestMatchers("/admin/**").hasRole("ADMIN")
        
        // Cả 'ADMIN' và 'USER' đều có thể truy cập /dashboard
        .requestMatchers("/dashboard").hasAnyRole("ADMIN", "USER")
        
        // Mọi người đều có thể truy cập trang chủ
        .requestMatchers("/").permitAll()
        
        // Bất kỳ yêu cầu nào khác đều cần xác thực
        .anyRequest().authenticated()
    );
    // ... các cấu hình khác
    return http.build();
}

Lưu ý quan trọng: Spring Security tự động thêm tiền tố ROLE_ vào giá trị bạn cung cấp. Ví dụ, nếu vai trò trong CSDL của bạn là ADMIN, bạn sẽ kiểm tra với hasRole('ADMIN') như sau:

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests(authorize -> authorize
        // Chỉ người dùng có vai trò 'ADMIN' mới được truy cập các URL bắt đầu bằng /admin/
        .requestMatchers("/admin/**").hasRole("ADMIN")
        
        // Cả 'ADMIN' và 'USER' đều có thể truy cập /dashboard
        .requestMatchers("/dashboard").hasAnyRole("ADMIN", "USER")
        
        // Mọi người đều có thể truy cập trang chủ
        .requestMatchers("/").permitAll()
        
        // Bất kỳ yêu cầu nào khác đều cần xác thực
        .anyRequest().authenticated()
    );
    // ... các cấu hình khác
    return http.build();
}

Ủy quyền dựa trên quyền hạn (Authority-Based) 

Phương pháp này cung cấp sự kiểm soát chi tiết hơn so với ủy quyền dựa trên vai trò.

Phân biệt Role và Authority:

  • Role (Vai trò): Thường là một nhóm các quyền. Ví dụ: vai trò ROLE_EDITOR.
  • Authority (Quyền hạn): Là một quyền hạn cụ thể, đơn lẻ. Ví dụ: product:read, product:write. Một ROLE_EDITOR có thể bao gồm cả hai quyền này.

Khi sử dụng các phương thức hasAuthority() hoặc hasAnyAuthority(), Spring Security sẽ so khớp chính xác giá trị bạn cung cấp mà không tự động thêm tiền tố ROLE_.

Cách làm: Sử dụng các phương thức hasAuthority() hoặc hasAnyAuthority() trong cấu hình bảo mật. Lưu ý Spring Security không tự động thêm tiền tố ROLE_ với hasAuthority().

Ví dụ:

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests(authorize -> authorize
        // Yêu cầu quyền 'product:delete' cụ thể
        .requestMatchers("/products/delete/**").hasAuthority("product:delete")
        
        // Để kiểm tra vai trò ADMIN bằng authority, bạn phải cung cấp cả tiền tố
        .requestMatchers("/admin/**").hasAuthority("ROLE_ADMIN")
        
        .anyRequest().authenticated()
    );
    return http.build();
}

Hướng dẫn cài đặt cấu hình và làm việc với Spring Boot security

Thêm Dependency (Maven)

Đây là bước đầu tiên và bắt buộc, giúp bạn tích hợp thư viện Spring Security vào dự án, là nền tảng để kích hoạt các tính năng bảo mật. 

Trong file pom.xml, hãy thêm dependency sau:

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

Sau khi thêm, mọi endpoint của bạn sẽ được bảo vệ ngay lập tức.

Tạo lớp cấu hình bảo mật

Sau khi có thư viện, bước này tạo ra một lớp để bạn có thể định nghĩa và tùy chỉnh các quy tắc bảo mật riêng cho ứng dụng của mình.

Tạo một lớp SecurityConfig và đánh dấu nó với @Configuration. Đây sẽ là nơi chúng ta định nghĩa các quy tắc bảo mật:

import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;

@Configuration
@EnableWebSecurity // Bật tính năng bảo mật web của Spring Security
public class SecurityConfig {
    // Các bean cấu hình sẽ được đặt ở đây
}

Cấu hình SecurityFilterChain và HttpSecurity 

Bước này cho phép bạn kiểm soát cách các request HTTP được xử lý về mặt bảo mật, ví dụ như trang nào được phép truy cập tự do và trang nào cần xác thực.

Hãy tạo một bean SecurityFilterChain để tùy chỉnh quy tắc. Ví dụ, chúng ta sẽ cho phép mọi người truy cập vào trang chủ (/) và yêu cầu xác thực cho tất cả các trang còn lại như sau:

import org.springframework.context.annotation.Bean;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;

@Configuration
// ...
public class SecurityConfig {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(authorize -> authorize
                .requestMatchers("/", "/home").permitAll() // Cho phép truy cập không cần xác thực
                .anyRequest().authenticated() // Mọi request khác đều cần xác thực
            )
            .formLogin(formLogin -> formLogin // Cấu hình form đăng nhập
                .loginPage("/login") // Đường dẫn tới trang đăng nhập tùy chỉnh (nếu có)
                .permitAll()
            )
            .logout(logout -> logout.permitAll()); // Cho phép tất cả người dùng logout

        return http.build();
    }
}

Cấu hình UserDetailsService và PasswordEncoder

Cuối cùng, bước này định nghĩa cách ứng dụng xác thực người dùng và đảm bảo mật khẩu được lưu trữ an toàn bằng cách mã hóa chúng.

Hãy định nghĩa một bean PasswordEncoder và một bean UserDetailsService để tạo ra một vài người dùng trong bộ nhớ như sau:

import org.springframework.security.core.userdetails.User;
import org.springframework.security.core.userdetails.UserDetails;
import org.springframework.security.core.userdetails.UserDetailsService;
import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder;
import org.springframework.security.crypto.password.PasswordEncoder;
import org.springframework.security.provisioning.InMemoryUserDetailsManager;

@Configuration
// ...
public class SecurityConfig {

    // ... bean SecurityFilterChain ở trên

    @Bean
    public PasswordEncoder passwordEncoder() {
        // Sử dụng BCrypt để mã hóa mật khẩu
        return new BCryptPasswordEncoder();
    }

    @Bean
    public UserDetailsService userDetailsService() {
        // Tạo người dùng admin
        UserDetails admin = User.builder()
                .username("admin")
                .password(passwordEncoder().encode("admin123")) // Mật khẩu phải được mã hóa
                .roles("ADMIN")
                .build();

        // Tạo người dùng user
        UserDetails user = User.builder()
                .username("user")
                .password(passwordEncoder().encode("user123"))
                .roles("USER")
                .build();
        
        // Quản lý người dùng trong bộ nhớ
        return new InMemoryUserDetailsManager(admin, user);
    }
}

Với cấu hình này, bạn đã thiết lập một hệ thống bảo mật cơ bản với 2 người dùng có vai trò khác nhau.

Tóm lại, ví dụ trên giúp bạn hình dung phần nào cách Spring Boot Security giúp đơn giản hóa việc cấu hình bảo mật so với Spring Security truyền thống, thông qua việc cung cấp các cơ chế tự động và yêu cầu ít code hơn để thiết lập một hệ thống bảo mật hoạt động ngay lập tức.

Các chủ đề nâng cao và bảo mật toàn diện

Bảo vệ chống lại các lỗ hổng phổ biến

Spring Security cung cấp các cơ chế phòng thủ mạnh mẽ được bật sẵn để chống lại các cuộc tấn công web phổ biến dưới đây:

  1. CSRF (Cross-Site Request Forgery): 

Đây là kiểu tấn công lừa người dùng thực hiện các hành động họ không mong muốn.

Cơ chế bảo vệ: Spring Security bật bảo vệ CSRF mặc định cho các ứng dụng sử dụng session. Nó yêu cầu một token bí mật phải được gửi kèm với các request thay đổi trạng thái (POST, PUT, DELETE). Thymeleaf và các template engine khác thường tự động tích hợp token này. Đối với API stateless (như JWT), bạn có thể tắt tính năng này.

  1. CORS (Cross-Origin Resource Sharing): 

Đây là một cơ chế của trình duyệt nhằm kiểm soát các request được gửi từ một domain khác với domain của server.

Khi frontend và backend của bạn chạy trên hai domain khác nhau, bạn cần cấu hình CORS. Trong Spring Security, bạn có thể định nghĩa một CorsConfigurationSource bean để chỉ định các origin, method, và header được phép.

  1. XSS (Cross-Site Scripting): 

Tấn công này xảy ra khi kẻ xấu chèn các đoạn script độc hại vào trang web của bạn để thực thi trên trình duyệt của người dùng khác.

Cơ chế bảo vệ: Mặc dù không phải là nhiệm vụ chính, Spring Security góp phần phòng chống bằng cách thiết lập các header bảo mật (X-XSS-Protection). Tuy nhiên, biện pháp quan trọng nhất là luôn làm sạch (sanitize) và mã hóa (escape) dữ liệu đầu vào từ người dùng và sử dụng các template engine như Thymeleaf có khả năng escape tự động.

  1. Session Fixation: 

Kẻ tấn công lừa người dùng sử dụng một session ID mà chúng đã biết trước.

Cơ chế bảo vệ: Spring Security tự động ngăn chặn điều này. Khi người dùng đăng nhập thành công, nó sẽ hủy session cũ và tạo một session hoàn toàn mới, làm cho session ID mà kẻ tấn công biết trở nên vô dụng.

Quản lý phiên (Session Management)

Việc kiểm soát cách các phiên được tạo và duy trì là rất quan trọng, đặc biệt khi phân biệt giữa ứng dụng web truyền thống và API.

  • Chính sách tạo phiên:

Bạn có thể cấu hình Spring Security để quyết định khi nào tạo session.

  • IF_REQUIRED: Mặc định, chỉ tạo session nếu cần.
  • STATELESS: Không tạo hoặc sử dụng session. Đây là lựa chọn bắt buộc cho các RESTful API sử dụng token (như JWT) để duy trì trạng thái phía client.
  • Phát hiện phiên hết hạn: Bạn có thể cấu hình để xử lý khi session của người dùng hết hạn, ví dụ như chuyển hướng họ về trang đăng nhập.

Ví dụ cấu hình cho API stateless:

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http
        // ... các cấu hình khác
        .sessionManagement(session -> 
            session.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
        );
    return http.build();
}

Kiểm thử bảo mật (Security Testing)

Viết test cho các quy tắc bảo mật là một phần không thể thiếu để đảm bảo chúng hoạt động đúng như mong đợi.

Để kiểm thử các tính năng bảo mật trong ứng dụng Spring Boot, bạn có thể sử dụng các công cụ chuyên dụng do chính Spring Security cung cấp. Công cụ chính bao gồm dependency spring-security-test và MockMvc.

Cách thực hiện rất đơn giản, bao gồm các bước sau:

  • Thêm dependency: Đầu tiên, bạn cần thêm spring-security-test vào file pom.xml với scope test.
  • Sử dụng MockMvc: Tiếp theo, hãy dùng MockMvc để tạo các request HTTP giả lập đến các endpoint của bạn. Công cụ này giúp bạn kiểm tra xem một endpoint công khai có trả về mã 200 OK hay không, và một endpoint được bảo vệ sẽ trả về 401 Unauthorized (khi chưa xác thực) hoặc 403 Forbidden (khi không có quyền truy cập).
  • Giả lập người dùng: Cuối cùng, để kiểm tra logic phân quyền, bạn có thể sử dụng các annotation như @WithMockUser. Annotation này cho phép bạn thực thi một bài test như thể đang có một người dùng đã đăng nhập với tên, mật khẩu và vai trò (roles/authorities) cụ thể, giúp việc kiểm tra các quy tắc bảo mật trở nên dễ dàng và trực quan.

Ví dụ một bài test:

@SpringBootTest
@AutoConfigureMockMvc
class SecurityTests {

    @Autowired
    private MockMvc mockMvc;

    @Test
    void accessAdminPage_FailsWithoutAuth() throws Exception {
        // Kiểm tra rằng truy cập /admin sẽ bị chuyển hướng đến trang login (status 302)
        // khi chưa xác thực.
        mockMvc.perform(get("/admin"))
               .andExpect(status().is3xxRedirection());
    }

    @Test
    @WithMockUser(username = "admin", roles = {"ADMIN"})
    void accessAdminPage_SucceedsWithAdminRole() throws Exception {
        // Với @WithMockUser, bài test này chạy như một người dùng 'admin' có vai trò 'ADMIN'
        // đã đăng nhập. Do đó, request sẽ thành công (status 200).
        mockMvc.perform(get("/admin"))
               .andExpect(status().isOk());
    }
}

Bảo mật ở cấp độ phương thức (Method-Level Security) 

Thay vì chỉ bảo vệ các URL, bạn có thể bảo vệ trực tiếp các phương thức trong tầng Service hoặc Controller. Cũng như khi bạn muốn kiểm soát quyền truy cập chi tiết hơn ở mức hàm. Điều này giúp mã nguồn an toàn và rõ ràng hơn

Đầu tiên, bạn cần kích hoạt tính năng này bằng cách thêm annotation @EnableMethodSecurity vào một lớp cấu hình.

Sau đó, bạn sử dụng các annotation sau trên các phương thức cần bảo vệ:

  • @Secured: Cách đơn giản nhất. Bạn truyền vào một mảng các vai trò hoặc quyền.
    • Ví dụ: @Secured("ROLE_ADMIN")
  • @RolesAllowed: Annotation chuẩn của JSR-250, chỉ dành cho vai trò. Không cần tiền tố ROLE_.
    • Ví dụ: @RolesAllowed("ADMIN")
  • @PreAuthorize / @PostAuthorize: Mạnh mẽ và linh hoạt nhất, sử dụng Ngôn ngữ Biểu thức Spring (SpEL).
    • @PreAuthorize: Kiểm tra quyền trước khi phương thức được thực thi.
    • @PostAuthorize: Kiểm tra quyền sau khi phương thức đã thực thi, có thể dùng để kiểm tra giá trị trả về (returnObject).

Ví dụ trong Service Layer:

import org.springframework.security.access.prepost.PreAuthorize;
import org.springframework.stereotype.Service;

@Service
public class ProductService {

    // Chỉ người dùng có vai trò ADMIN mới có thể xóa sản phẩm
    @PreAuthorize("hasRole('ADMIN')")
    public void deleteProduct(Long id) {
        // logic xóa sản phẩm
        System.out.println("Đã xóa sản phẩm với ID: " + id);
    }

    // Người dùng phải có quyền 'product:read' để xem sản phẩm
    @PreAuthorize("hasAuthority('product:read')")
    public Product getProductById(Long id) {
        // logic lấy sản phẩm
        return new Product(id, "Sample Product");
    }
    
    // Chỉ người dùng tạo ra đơn hàng mới có thể xem chi tiết đơn hàng đó
    @PreAuthorize("#username == authentication.principal.username")
    public Order getOrderForUser(Long orderId, String username) {
        // logic phức tạp hơn
        return new Order(orderId);
    }
}

Các phương pháp tốt nhất để sử dụng Spring Boot security

Việc triển khai các tính năng bảo mật chỉ là bước đầu. Để xây dựng một ứng dụng thực sự an toàn và dễ bảo trì, bạn cần tuân thủ các phương pháp thực hành tốt nhất sau đây.

1. Cấu trúc dự án rõ ràng

Hãy tổ chức các lớp liên quan đến bảo mật vào một package riêng, ví dụ com.example.yourapp.security. Điều này bao gồm các lớp cấu hình (SecurityConfig), các bộ lọc tùy chỉnh (JwtRequestFilter), các lớp dịch vụ người dùng (UserDetailsService), và các model liên quan.

Một cấu trúc rõ ràng giúp mã nguồn dễ đọc, dễ quản lý và dễ dàng tìm kiếm khi cần gỡ lỗi hoặc nâng cấp.

2. Luôn sử dụng HTTPS trong môi trường Production

HTTPS là yêu cầu bắt buộc cho bất kỳ ứng dụng nào trong môi trường production. Nó mã hóa toàn bộ dữ liệu truyền tải giữa client và server, bảo vệ thông tin nhạy cảm như mật khẩu và token khỏi các cuộc tấn công nghe lén (man-in-the-middle).

3. Luôn cập nhật các Dependency

Thế giới bảo mật luôn biến động, các lỗ hổng mới được phát hiện liên tục. Hãy thường xuyên kiểm tra và cập nhật các dependency của dự án, đặc biệt là spring-boot-starter-security, lên phiên bản mới nhất. Việc này đảm bảo bạn nhận được các bản vá lỗi bảo mật quan trọng từ cộng đồng.

4. Nguyên tắc đặc quyền tối thiểu (Principle of Least Privilege)

Đây là một trong những nguyên tắc nền tảng của an toàn thông tin. Hãy đảm bảo rằng mỗi người dùng hoặc hệ thống chỉ được cấp những quyền tối thiểu cần thiết để thực hiện chức năng của mình. Ví dụ, một người dùng thông thường không nên có quyền truy cập vào các trang quản trị, và một API chỉ đọc dữ liệu không nên có quyền ghi vào cơ sở dữ liệu.

5. Xử lý ngoại lệ (Exception Handling) tùy chỉnh

Thay vì hiển thị các trang lỗi mặc định của Spring, hãy tùy chỉnh chúng để mang lại trải nghiệm tốt hơn cho người dùng và API.

  • AuthenticationEntryPoint: Tùy chỉnh để xử lý các lỗi khi người dùng chưa được xác thực (ví dụ: trả về lỗi JSON 401 cho API thay vì chuyển hướng đến trang đăng nhập).
  • AccessDeniedHandler: Tùy chỉnh để xử lý khi người dùng đã xác thực nhưng không đủ quyền truy cập (ví dụ: trả về lỗi JSON 403 với thông báo thân thiện).

6. Logging và Giám sát các sự kiện bảo mật

Hãy ghi log (ghi nhật ký) lại các sự kiện bảo mật quan trọng, bao gồm:

  • Đăng nhập thành công và thất bại.
  • Các truy cập bị từ chối (lỗi 403).
  • Các thay đổi về quyền hạn của người dùng.

Việc giám sát các log này giúp bạn phát hiện sớm các hoạt động đáng ngờ hoặc các cuộc tấn công tiềm tàng.

7. Bảo vệ thông tin nhạy cảm

Không bao giờ hardcode các thông tin nhạy cảm như mật khẩu database, API keys, hay secret key của JWT trực tiếp vào mã nguồn hoặc file properties. Thay vào đó, hãy sử dụng các phương pháp an toàn hơn như:

  • Biến môi trường (Environment Variables).
  • Các hệ thống quản lý bí mật chuyên dụng như HashiCorp Vault, AWS Secrets Manager, hoặc Azure Key Vault.

Các câu hỏi thường gặp về Spring Boot Security

Về cơ bản bạn cần:

  1. Tắt tính năng CSRF và quản lý phiên (session) của Spring Security.
  2. Tạo một bộ lọc (filter) để xử lý việc tạo token sau khi người dùng đăng nhập thành công.
  3. Tạo một bộ lọc khác để xác thực token từ mỗi request đến và thiết lập SecurityContext nếu token hợp lệ.

Tại sao tôi nên dùng JWT cho REST API thay vì Session mặc định?

Vì REST API được thiết kế theo nguyên tắc phi trạng thái (stateless).

Session mặc định lưu trữ trạng thái đăng nhập trên server, điều này gây khó khăn cho việc mở rộng (scale) ứng dụng và không phù hợp với kiến trúc microservices.

Còn JWT (JSON Web Token) chứa tất cả thông tin xác thực bên trong chính nó. Server không cần lưu trữ gì cả, giúp hệ thống dễ dàng mở rộng và các service có thể xác thực token một cách độc lập.

Làm thế nào để bỏ qua bảo mật cho các tài nguyên tĩnh như CSS, JavaScript?

Bạn có thể cấu hình trong SecurityFilterChain để cho phép tất cả các request đến các thư mục chứa tài nguyên tĩnh như sau:

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests(authorize -> authorize
        // Cho phép truy cập không cần xác thực vào các tài nguyên tĩnh
        .requestMatchers("/css/**", "/js/**", "/images/**").permitAll()
        .anyRequest().authenticated()
    );
    return http.build();
}

Tổng kết

Spring Boot Security đã đơn giản hóa đáng kể việc bảo mật ứng dụng Java. Nhờ cơ chế tự động cấu hình và một bộ công cụ toàn diện, nó giúp bạn dễ dàng triển khai mọi thứ từ xác thực cơ bản đến các cơ chế phòng thủ nâng cao. Bằng cách áp dụng những kiến thức trong bài viết này, bạn có thể tự tin xây dựng nên những ứng dụng không chỉ giàu tính năng mà còn vững chắc và an toàn.

Chia sẻ bài viết
TAG:
Chuyên môn ITJava
TÁC GIẢ
Tien Tran
Tien Tran

iOS Developer

Có 4 năm kinh nghiệm trong lĩnh vực phát triển ứng dụng mobile, được chứng minh qua lịch sử làm việc ở các công ty lớn (VCCorp, KiotViet, Vega Fintech). Với đam mê tìm hiểu, nghiên cứu những kiến thức chuyên môn cần có của một lập trình viên mobile hiện nay như Swift, Objective C, Flutter, Kotlin,... Tiến mong muốn chia sẻ kinh nghiệm làm việc và truyền cảm hứng cho mọi người muốn theo đuổi con đường trở thành một nhà phát triển ứng dụng di động chuyên nghiệp trong tương lai.