Spring Security — authentication, authorization আর নিরাপদ API

১ · দুটি প্রশ্ন — “আপনি কে?” আর “আপনি কী করতে পারেন?”

পর্ব ৫১-এ আপনি একটি অনলাইন দোকানের API বানিয়েছেন। এখন সেটা ইন্টারনেটে খোলা। যে কেউ পণ্যের তালিকা দেখতে পারবেন — এটা ভালো। কিন্তু একই দরজা দিয়ে যে কেউ যদি চালের দাম ১ টাকা করে দিতে পারেন, বা অন্যের অর্ডারের ঠিকানা আর ফোন নম্বর দেখতে পারেন, তাহলে দোকানটি এক দিনও টিকবে না। এই পর্বের বিষয় সেই দরজাগুলো পাহারা দেওয়া।

নিরাপত্তার শুরুতেই দুটি প্রশ্ন আলাদা করতে হয়। প্রথমটি authentication — “আপনি কে?” পাসওয়ার্ড, OTP বা token দিয়ে এর উত্তর মেলে। দ্বিতীয়টি authorization — “পরিচয় তো জানলাম, এই কাজটি কি আপনি করতে পারেন?” প্রথম প্রশ্নের উত্তর না মিললে HTTP-তে 401, দ্বিতীয়টির উত্তর “না” হলে 403. পর্ব ৫১-এর status code-এর টেবিলে এই দুটি দেখেছেন; এবার সেগুলো আসলে কে, কীভাবে দেয়, তা দেখবেন।

Spring Security ঠিক এই গেট আর দরজাগুলো বানায়। প্রতিটি request আপনার controller-এ পৌঁছানোর আগে কয়েকটি পাহারাদারের সারি পার হয়: কেউ পরিচয় যাচাই করে, কেউ নিয়ম মিলিয়ে দেখে, কেউ ব্যর্থ হলে ঠিক উত্তরটি পাঠায়। আপনার controller-এর কোড চলে কেবল সব পাহারা পার হলে।

কোন বিপদ থেকে বাঁচাচ্ছি — একটি ছোট threat model

নিরাপত্তার কাজ শুরু হয় একটি প্রশ্ন দিয়ে: কে, কী ক্ষতি করতে চাইতে পারে, আর কোন পথে? এই চিন্তাকে বলে threat model. আমাদের দোকানের API-র জন্য প্রধান ঝুঁকি আর তাদের প্রতিরক্ষা এক টেবিলে:

তৃতীয় সারিটির নাম Broken Access Control. OWASP Top 10-এর ২০২১ সালের তালিকায় এটি প্রথম স্থানে উঠে আসে — পরীক্ষা করা অ্যাপগুলোতে অন্য যেকোনো ধরনের দুর্বলতার চেয়ে এটি বেশি পাওয়া গেছে। আর SQL injection-এর প্রতিরক্ষা আপনি পর্ব ৪৯-এ PreparedStatement দিয়ে শিখেছেন; এই পর্বে সেটা আবার বলব না।

২ · filter chain — controller-এর আগে পাহারাদারের সারি

পর্ব ৪৮-এ Chain of Responsibility pattern দেখেছেন: একটি অনুরোধ কয়েকটি handler-এর শিকল ধরে এগোয়, আর যেকোনো handler চাইলে সেখানেই থামিয়ে দিতে পারে। Java-র ওয়েব সার্ভারে এর রূপ হলো servlet filter: Tomcat প্রতিটি request-কে DispatcherServlet-এ দেওয়ার আগে কয়েকটি filter-এর ভেতর দিয়ে পাঠায়। Spring Security পুরোটাই এই filter-এর ওপর দাঁড়িয়ে।

তিনটি স্তর আছে, আর নামগুলো প্রথমে ভারী শোনায়:

পরিচয় যাচাই সফল হলে ফলটি রাখা হয় SecurityContextHolder-এ। ডিফল্টে এটি একটি ThreadLocal: যে thread এই request সামলাচ্ছে, শুধু সেই thread দেখতে পায়। ভেতরে থাকে একটি SecurityContext, আর তার ভেতরে একটি Authentication object — তিনটি মূল তথ্যসহ: principal (কে — সাধারণত username বা ফোন নম্বর), credentials (পাসওয়ার্ড, যাচাইয়ের পরে মুছে ফেলা হয়), আর authorities (কী কী অনুমতি — যেমন ROLE_CUSTOMER). আপনার কোডের যেকোনো জায়গা থেকে এটা পড়া যায়:

Authentication auth = SecurityContextHolder.getContext().getAuthentication();
String who = auth.getName();                       // যেমন "01712345678"
var roles = auth.getAuthorities();                 // যেমন [ROLE_CUSTOMER]

এবার একটি request পুরো শিকল ধরে কীভাবে এগোয়, তিনটি পরিস্থিতিতে দেখুন: token নেই, token আছে কিন্তু role ভুল, আর token ও role দুটিই ঠিক। endpoint-টি দাম বদলানোর — PUT /api/v1/products/7/price, যা শুধু ADMIN পারবেন।

PUT /api/v1/products/7/price
Content-Type: application/json
(Authorization header নেই)

Tomcat → DelegatingFilterProxy → FilterChainProxy
  /api/** মেলে → API-র SecurityFilterChain

BearerTokenAuthenticationFilter: token নেই → কিছু করল না
AnonymousAuthenticationFilter:
  SecurityContext ← anonymousUser [ROLE_ANONYMOUS]

AuthorizationFilter: নিয়ম hasRole('ADMIN') → না
ExceptionTranslationFilter: ব্যবহারকারী anonymous
  → 401 Unauthorized
  → WWW-Authenticate: Bearer
controller চলেইনি

Authorization: Bearer eyJhbGciOi...
BearerTokenAuthenticationFilter:
  স্বাক্ষর ✓  মেয়াদ ✓
  SecurityContext ← rahim [ROLE_CUSTOMER]

AuthorizationFilter: hasRole('ADMIN')?
  rahim-এর আছে শুধু ROLE_CUSTOMER → না
ExceptionTranslationFilter: পরিচয় জানা
  → 403 Forbidden

SecurityContext ← admin [ROLE_ADMIN]
AuthorizationFilter: hasRole('ADMIN') → হ্যাঁ
  → DispatcherServlet → ProductController.changePrice(..)
200 OK  {"id":7,"price":440}

উত্তর চলে গেল
SecurityContextHolder.clearContext()
thread pool-এ ফিরে যাওয়া thread-এ
আগের মানুষের পরিচয় থেকে যায় না

ডেভেলপমেন্টের সময় কোন filter কোন ক্রমে চলছে দেখতে চাইলে logging.level.org.springframework.security=TRACE দিন — অ্যাপ চালুর সময় পুরো তালিকা আর প্রতিটি request-এর সিদ্ধান্ত log-এ আসবে। আসল সার্ভারে এই স্তর বন্ধ রাখুন।

৩ · starter যোগ করলেই সব বন্ধ — তারপর SecurityFilterChain দিয়ে খোলা

পর্ব ৫০-এর starter মনে আছে? pom.xml-এ একটি লাইন যোগ করুন:

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

আর কিছু না লিখেই অ্যাপ চালান। Spring Boot-এর auto-configuration classpath-এ Spring Security দেখে কয়েকটি কাজ নিজে করে ফেলে:

• সব endpoint বন্ধ: পণ্যের তালিকাও এখন লগইন ছাড়া দেখা যায় না।
• একজন ব্যবহারকারী তৈরি: নাম user, আর প্রতিবার চালুর সময় একটি নতুন random পাসওয়ার্ড, যা log-এ ছাপা হয়।
• লগইনের দুটি পথ চালু: ব্রাউজারের জন্য form login পাতা, আর অন্য client-এর জন্য HTTP Basic.
• সুরক্ষা চালু: CSRF সুরক্ষা, কয়েকটি security header, আর লগইনের পর session id বদলানো।

Using generated security password: 3f1c...-....-....-............

This generated password is for development use only. Your security
configuration must be updated before running your application in production.

হুবহু লেখাটি সংস্করণভেদে একটু আলাদা হতে পারে, কিন্তু অর্থ একই: এটা শুধু ডেভেলপমেন্টের জন্য। এবার curl দিয়ে পণ্যের তালিকা চাইলে:

$ curl -i http://localhost:8080/api/v1/products
HTTP/1.1 401
WWW-Authenticate: Basic realm="Realm"
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Cache-Control: no-cache, no-store, max-age=0, must-revalidate

এই ডিফল্টটি ইচ্ছা করেই কড়া: ভুলে বন্ধ থাকলে কেউ অভিযোগ করবেন, ভুলে খোলা থাকলে হয়তো কেউ টেরই পাবেন না। এবার নিজের নিয়ম লিখুন। Spring Security 6 (Spring Boot 3.x)-এ এর উপায় একটি SecurityFilterChain bean, lambda দিয়ে লেখা:

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    SecurityFilterChain api(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers(HttpMethod.GET, "/api/v1/products/**").permitAll()      // দেখবেন সবাই
                .requestMatchers(HttpMethod.PUT, "/api/v1/products/*/price").hasRole("ADMIN")
                .requestMatchers("/api/v1/orders/**").hasAnyRole("CUSTOMER", "ADMIN")
                .requestMatchers("/actuator/health").permitAll()
                .anyRequest().authenticated())                                           // বাকি সব: পরিচয় লাগবে
            .httpBasic(Customizer.withDefaults());
        return http.build();
    }
}

দুটি জিনিস খেয়াল করুন। প্রথমত, নিয়মগুলো ওপর থেকে নিচে মেলানো হয়, আর প্রথম যেটি মেলে সেটিই প্রযোজ্য। তাই নির্দিষ্ট নিয়ম আগে, সাধারণ নিয়ম পরে, আর anyRequest() সবার শেষে। দ্বিতীয়ত, প্রথম নিয়মে HttpMethod.GET আছে — শুধু দেখা খোলা। এটা বাদ দিলে /api/v1/products/**-এর PUT-ও খোলা হয়ে যেত, আর পরের ADMIN-এর নিয়মটি কখনো পৌঁছাতই না (অনুশীলন ১)।

৪ · পাসওয়ার্ড রাখা — hash, salt আর ধীর হওয়ার গুণ

লগইনের জন্য সার্ভারকে পাসওয়ার্ড মিলিয়ে দেখতে হয়। কিন্তু পাসওয়ার্ড নিজে রাখা চলবে না। কারণ ধরে নিতে হবে, একদিন ডেটাবেসের কপি কারও হাতে যেতে পারে — ভুলে খোলা ব্যাকআপ, ফাঁস হওয়া পাসওয়ার্ড, ভেতরের কেউ। তখন প্রশ্ন একটাই: সেই কপি থেকে আসল পাসওয়ার্ড বের করা কত কঠিন? আর মানুষ একই পাসওয়ার্ড ইমেইল, ফেসবুক আর মোবাইল ব্যাংকিং-এ ব্যবহার করেন, তাই ক্ষতি আপনার দোকানে থেমে থাকে না।

উত্তর হলো cryptographic hash — এক দিকের রূপান্তর। পাসওয়ার্ড থেকে hash বানানো সহজ, hash থেকে পাসওয়ার্ড ফেরত বের করা কার্যত অসম্ভব। লগইনের সময় দেওয়া পাসওয়ার্ডের hash বানিয়ে জমানো hash-এর সাথে মেলানো হয়। কিন্তু সব hash এই কাজের উপযুক্ত নয়। ধাপে ধাপে দেখুন:

phone         password
01712345678   Dhaka@2026
01811111111   123456
ফাঁস হলে সঙ্গে সঙ্গে সবার পাসওয়ার্ড প্রকাশ্যে

01712345678   sha256 → 5e2b…a9
01811111111   sha256 → 8d96…92
01999999999   sha256 → 8d96…92   ← একই পাসওয়ার্ড, একই hash
আগে থেকে হিসাব করা তালিকায় "123456"-এর hash খুঁজে পাওয়া যায়

01811111111   salt=Q7x… hash=sha256(salt+pw) → 3a01…
01999999999   salt=Lm2… hash=sha256(salt+pw) → f4c8…
একই পাসওয়ার্ড, আলাদা hash; আগের তালিকা অকেজো
কিন্তু প্রতিটি অনুমান এখনো খুব সস্তা

{bcrypt}$2a$10$N9qo8uLOickgx2ZMRZoMye…
         │   │  └─ salt (২২ অক্ষর) আর hash
         │   └──── cost = 10 → 2^10 রাউন্ড
         └──────── অ্যালগরিদম
একটি অনুমানে এখন মিলিসেকেন্ডের বদলে ধরুন ~১০০ ms

দেওয়া পাসওয়ার্ড: "Dhaka@2026"
জমানো লেখা থেকে পড়ো: অ্যালগরিদম, cost, salt
একই salt আর cost দিয়ে আবার hash
নতুন hash == জমানো hash ?  সমান-সময়ের তুলনা
→ মিলেছে → লগইন সফল

কম্পিউটার দ্রুত হয়েছে → নতুন cost = 12
পুরোনো hash: $2a$10$…   নতুন hash: $2a$12$…
সফল লগইনের মুহূর্তে আসল পাসওয়ার্ড হাতে থাকে
→ নতুন cost-এ আবার hash করে জমাও

এবার JDK দিয়েই একটি ধীর hash চালিয়ে দেখুন। Spring লাগবে না: JDK-তে PBKDF2 আছে (SecretKeyFactory), আর সমান-সময়ের তুলনার জন্য MessageDigest.isEqual. hash নিজে ছাপানো হয়নি, শুধু দৈর্ঘ্য আর মিলল কি না:

import javax.crypto.SecretKeyFactory;
import javax.crypto.spec.PBEKeySpec;
import java.security.MessageDigest;
import static java.nio.charset.StandardCharsets.UTF_8;

class Main {
    static final int ITERATIONS = 600_000;                       // cost factor: প্রতিটি অনুমানের খরচ
    static byte[] hash(String password, byte[] salt) throws Exception {
        var spec = new PBEKeySpec(password.toCharArray(), salt, ITERATIONS, 256);
        try { return SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256").generateSecret(spec).getEncoded(); }
        finally { spec.clearPassword(); }
    }
    static boolean verify(String attempt, byte[] salt, byte[] stored) throws Exception {
        return MessageDigest.isEqual(hash(attempt, salt), stored);    // constant-time তুলনা
    }
    public static void main(String[] args) throws Exception {
        byte[] salt = "demo-salt-16byte".getBytes(UTF_8);              // শুধু ডেমো! আসলে SecureRandom
        byte[] stored = hash("Dhaka@2026", salt);                      // সাইন-আপের সময় একবার
        System.out.println("stored: salt " + salt.length + " bytes, hash " + stored.length + " bytes");
        System.out.println("login 'Dhaka@2026' -> " + verify("Dhaka@2026", salt, stored));
        System.out.println("login 'dhaka@2026' -> " + verify("dhaka@2026", salt, stored));
        byte[] salt2 = "other-salt-16byt".getBytes(UTF_8);
        System.out.println("same password, other salt, same hash? " + MessageDigest.isEqual(stored, hash("Dhaka@2026", salt2)));
    }
}

Spring-এ — PasswordEncoder আর UserDetailsService

Spring Security-তে এই কাজের interface PasswordEncoder: encode(raw) সাইন-আপের সময় hash বানায়, matches(raw, stored) লগইনে মেলায়। সবচেয়ে প্রচলিত বাছাই PasswordEncoderFactories.createDelegatingPasswordEncoder(). এটি নতুন পাসওয়ার্ড bcrypt দিয়ে hash করে আর সামনে লিখে দেয় {bcrypt}. পড়ার সময় উপসর্গ দেখে ঠিক encoder বাছে ({argon2}, {pbkdf2}…), তাই অ্যালগরিদম বদলালেও পুরোনো ব্যবহারকারীরা লগইন করতে পারেন।

ব্যবহারকারীর তথ্য কোথা থেকে আসবে, Spring জানতে চায় একটি UserDetailsService-এর কাছে। দোকানের গ্রাহকরা লগইন করেন ফোন নম্বর দিয়ে:

@Bean
PasswordEncoder passwordEncoder() {
    return PasswordEncoderFactories.createDelegatingPasswordEncoder();   // নতুন hash: {bcrypt}$2a$10$...
}

@Service
public class ShopUserDetailsService implements UserDetailsService {
    private final CustomerRepository customers;
    public ShopUserDetailsService(CustomerRepository customers) { this.customers = customers; }

    @Override
    public UserDetails loadUserByUsername(String phone) {
        Customer c = customers.findByPhone(phone)
                .orElseThrow(() -> new UsernameNotFoundException("unknown user"));
        return User.withUsername(c.getPhone())
                   .password(c.getPasswordHash())        // ডেটাবেসে শুধু hash
                   .roles(c.getRole().name())            // CUSTOMER → ROLE_CUSTOMER
                   .build();
    }
}

// সাইন-আপের সময় (service-এ):
customer.setPasswordHash(passwordEncoder.encode(request.password()));

Spring এই দুটি bean দেখে নিজেই লগইনের পুরো যাচাই সাজিয়ে নেয়। ফোন নম্বর না পাওয়া গেলে আর পাসওয়ার্ড ভুল হলে Spring ডিফল্টে একই ব্যর্থতা দেখায় — “ফোন নম্বর বা পাসওয়ার্ড ভুল”। আলাদা বার্তা দিলে যে কেউ জেনে যাবে কোন নম্বরগুলো নিবন্ধিত। BCryptPasswordEncoder-এর ডিফল্ট cost ১০; প্রতি ১ বাড়ালে সময় দ্বিগুণ — নিজের সার্ভারে মেপে বেছে নিন। আর মনে রাখুন, bcrypt পাসওয়ার্ডের প্রথম ৭২ byte-ই ব্যবহার করে।

৫ · লগইনের পরে — session, token আর JWT

HTTP stateless: প্রতিটি request নতুন, সার্ভার আগেরটি মনে রাখে না। তাহলে একবার লগইন করার পর পরের request-এ “আমি রহিম” কীভাবে প্রমাণ হবে? প্রতিবার পাসওয়ার্ড পাঠানো ঝুঁকিপূর্ণ আর ধীর (প্রতিবার ধীর hash!)। চারটি প্রচলিত উপায়:

session-এ লগইনের মুহূর্তে Spring session id বদলে দেয়, যাতে লগইনের আগে কারও জানা id লগইনের পরে কাজে না লাগে (session fixation সুরক্ষা)। মোবাইল অ্যাপের API-তে সাধারণত token ব্যবহার হয়, আর token পাঠানো হয় একটি header-এ: Authorization: Bearer <token>. যার কাছে এই token, সার্ভার তাকেই মালিক ধরে — তাই নাম bearer token, বাসের টিকিটের মতো।

JWT-এর ভেতরে কী থাকে

JWT (JSON Web Token, RFC 7519) তিনটি অংশ, মাঝে বিন্দু: header.payload.signature. header বলে কোন অ্যালগরিদমে স্বাক্ষর ({"alg":"HS256"})। payload-এ কয়েকটি claim: sub (কে), exp (কখন মেয়াদ শেষ, ১৯৭০ থেকে সেকেন্ডে), iat (কখন দেওয়া), iss (কে দিয়েছে), আর নিজের claim যেমন role. প্রথম দুটি অংশ শুধু JSON, URL-এ নিরাপদ Base64URL-এ লেখা। তৃতীয় অংশ HMAC বা digital signature — প্রথম দুটি অংশের ওপর গোপন key দিয়ে বানানো স্বাক্ষর।

নিচের প্রোগ্রামে JDK-র Mac (HmacSHA256) আর Base64 দিয়ে একটি JWT-এর মতো token বানানো আর যাচাই করা হয়েছে, সাথে অংশ ২-এর 401/403/200 সিদ্ধান্ত। সময় এখানে একটি সাধারণ সংখ্যা (now), যাতে ফল প্রতিবার একই হয়:

import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import java.security.MessageDigest;
import java.util.Base64;
import static java.nio.charset.StandardCharsets.UTF_8;

class Main {
    static final byte[] KEY = "demo-only-key-read-from-env-in-real-apps".getBytes(UTF_8);
    static String b64(byte[] b) { return Base64.getUrlEncoder().withoutPadding().encodeToString(b); }
    static String sign(String data) throws Exception {
        Mac mac = Mac.getInstance("HmacSHA256");
        mac.init(new SecretKeySpec(KEY, "HmacSHA256"));
        return b64(mac.doFinal(data.getBytes(UTF_8)));
    }
    static String issue(String claims) throws Exception {               // লগইন সফল হলে সার্ভার দেয়
        String hp = b64("{\"alg\":\"HS256\"}".getBytes(UTF_8)) + "." + b64(claims.getBytes(UTF_8));
        return hp + "." + sign(hp);
    }
    static int check(String token, String needRole, long now) throws Exception {
        if (token == null) return 401;                                  // পরিচয় নেই
        String[] p = token.split("\\.");
        if (p.length != 3 || !MessageDigest.isEqual(sign(p[0] + "." + p[1]).getBytes(UTF_8), p[2].getBytes(UTF_8))) return 401;
        String claims = new String(Base64.getUrlDecoder().decode(p[1]), UTF_8);
        if (now >= Long.parseLong(claims.replaceAll(".*\"exp\":(\\d+).*", "$1"))) return 401;   // মেয়াদ শেষ
        return claims.contains("\"role\":\"" + needRole + "\"") ? 200 : 403;                   // অনুমতি
    }
    public static void main(String[] args) throws Exception {
        String rahim = issue("{\"sub\":\"rahim\",\"role\":\"CUSTOMER\",\"exp\":2000}");
        String admin = issue("{\"sub\":\"admin\",\"role\":\"ADMIN\",\"exp\":2000}");
        String[] r = rahim.split("\\.");
        String forged = r[0] + "." + b64("{\"sub\":\"rahim\",\"role\":\"ADMIN\",\"exp\":2000}".getBytes(UTF_8)) + "." + r[2];
        System.out.println("payload: " + new String(Base64.getUrlDecoder().decode(r[1]), UTF_8));
        System.out.println("no token  PUT /prices -> " + check(null, "ADMIN", 1000));
        System.out.println("rahim     GET /orders -> " + check(rahim, "CUSTOMER", 1000));
        System.out.println("rahim     PUT /prices -> " + check(rahim, "ADMIN", 1000));
        System.out.println("forged    PUT /prices -> " + check(forged, "ADMIN", 1000));
        System.out.println("admin     PUT /prices -> " + check(admin, "ADMIN", 1000));
        System.out.println("admin at t=2500       -> " + check(admin, "ADMIN", 2500));
    }
}

এবার পুরো জীবনচক্রটি ধাপে ধাপে দেখুন — লগইন থেকে মেয়াদ শেষ পর্যন্ত:

POST /api/v1/auth/login     (শুধু HTTPS-এ)
{"phone":"01712345678","password":"••••••••"}
→ UserDetailsService + PasswordEncoder.matches → ✓

payload = {"sub":"01712345678","roles":["CUSTOMER"],
           "iat":…, "exp": iat + 15 মিনিট}
signature = HMAC-SHA256(header.payload, গোপন key)
200 {"accessToken":"eyJ…","refreshToken":"…"}

অ্যাপ: নিরাপদ স্টোরেজে রাখে (Android Keystore / iOS Keychain)
GET /api/v1/orders/mine
Authorization: Bearer eyJ…

অ্যালগরিদম প্রত্যাশিত? ✓   স্বাক্ষর ✓
exp > এখন? ✓   iss ঠিক? ✓
→ Authentication(01712345678, [ROLE_CUSTOMER])
→ 200 — ডেটাবেসে না গিয়েই পরিচয় জানা গেল

payload-এ "CUSTOMER" → "ADMIN"
স্বাক্ষর আবার হিসাব → মেলে না
→ 401  WWW-Authenticate: Bearer error="invalid_token"

১৫ মিনিট পর: exp পার → 401
অ্যাপ: POST /api/v1/auth/refresh {refreshToken}
সার্ভার: ডেটাবেসে refresh token বৈধ? বাতিল হয়নি?
→ নতুন access token (আর নতুন refresh token)

Spring-এ JWT — OAuth2 Resource Server

নিজে JWT যাচাইয়ের filter লিখবেন না। Spring Security-র OAuth2 Resource Server সমর্থন এই কাজ করে: spring-boot-starter-oauth2-resource-server যোগ করুন, token কে দেয় তা properties-এ বলুন, আর filter chain-এ এক লাইন। মোবাইল API-র জন্য পুরো কনফিগারেশন:

@Configuration
@EnableWebSecurity
@EnableMethodSecurity
public class ApiSecurityConfig {

    @Bean
    SecurityFilterChain api(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers(HttpMethod.GET, "/api/v1/products/**").permitAll()
                .requestMatchers("/api/v1/auth/**").permitAll()
                .requestMatchers(HttpMethod.PUT, "/api/v1/products/*/price").hasRole("ADMIN")
                .anyRequest().authenticated())
            .sessionManagement(s -> s.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
            .csrf(csrf -> csrf.disable())                 // কারণ: cookie নয়, Authorization header (অংশ ৭)
            .cors(Customizer.withDefaults())
            .oauth2ResourceServer(oauth -> oauth.jwt(Customizer.withDefaults()));
        return http.build();
    }
}

# token দেয় একটি আলাদা authorization server (যেমন Keycloak) — তার public key নিজে খুঁজে নেবে
spring.security.oauth2.resourceserver.jwt.issuer-uri=https://auth.example.com/realms/shop

ডিফল্টে Spring token-এর scope claim থেকে SCOPE_ উপসর্গওয়ালা authority বানায়। নিজের roles claim থেকে ROLE_ADMIN বানাতে একটি JwtAuthenticationConverter bean লাগে। আর নিজের অ্যাপই যদি token দেয়, HMAC key দিয়ে NimbusJwtDecoder.withSecretKey(key).build() একটি JwtDecoder bean বানায় — key আসবে environment variable থেকে (অংশ ৮)। অনেক service থাকলে অসমমিতিক স্বাক্ষর (RS256, ES256) ভালো: শুধু token দেওয়ার সার্ভারের কাছে private key, বাকিরা public key দিয়ে শুধু যাচাই করে, জাল করতে পারে না।

OAuth2 আর OpenID Connect — “Google দিয়ে লগইন”

অনেক অ্যাপে “Google দিয়ে চালিয়ে যান” বোতাম থাকে। এর পেছনে দুটি মান। OAuth 2.0 (RFC 6749, ২০১২) মূলত অনুমতি দেওয়ার কাঠামো: একটি অ্যাপ আপনার পাসওয়ার্ড না জেনেই আপনার পক্ষে সীমিত কাজের অনুমতি পায়। OpenID Connect (২০১৪) তার ওপর পরিচয়ের স্তর যোগ করে — একটি ID token, যা বলে “ইনি Google-এর এই ব্যবহারকারী”। সংক্ষেপে: আপনার অ্যাপ ব্যবহারকারীকে Google-এর লগইন পাতায় পাঠায়, সেখানে লগইনের পর Google একটি ক্ষণস্থায়ী code দেয়, আর আপনার সার্ভার সেই code দিয়ে সরাসরি Google থেকে token নেয় — মোবাইল আর ব্রাউজার অ্যাপে সাথে PKCE. আপনার অ্যাপ Google-এর পাসওয়ার্ড কখনো দেখে না। Spring-এ spring-boot-starter-oauth2-client আর http.oauth2Login(...) দিয়ে এটা কয়েক লাইনের কাজ।

৬ · method security আর ownership — “গ্রাহক শুধু নিজের অর্ডার দেখবেন”

URL-এর নিয়ম মোটা দাগের পাহারা: কোন পথে কোন role. কিন্তু নিয়ম অনেক সময় ব্যবসার ভেতরে থাকে, আর একই service method অনেক controller থেকে ডাকা হতে পারে। তাই দ্বিতীয় স্তর — method security. configuration class-এ @EnableMethodSecurity দিলে (Spring Security 5.6 থেকে; পুরোনো কোডে @EnableGlobalMethodSecurity) method-এর ওপর নিয়ম লেখা যায়:

@Service
public class ProductService {

    @PreAuthorize("hasRole('ADMIN')")                         // method চলার আগে পরীক্ষা
    @Transactional
    public ProductResponse changePrice(long id, BigDecimal newPrice) { ... }
}

এখন কেউ ভুল করে আরেকটি controller থেকে changePrice ডাকলেও, বা URL-এর নিয়মে ফাঁক থাকলেও, ADMIN ছাড়া কেউ দাম বদলাতে পারবেন না। Spring এটা করে AOP proxy দিয়ে — পর্ব ৫১-এর @Transactional-এর মতোই, তাই একই ফাঁদ: একই class-এর ভেতর থেকে ডাকলে পরীক্ষা হয় না।

role যথেষ্ট নয় — ownership check

রহিম আর করিম দুজনেই CUSTOMER. রহিমের অর্ডারের পাতা /api/v1/orders/1001. তিনি কৌতূহলে URL-এ লিখলেন 1002. URL-এর নিয়ম বলে “CUSTOMER যেতে পারবেন” — পাস। অর্ডারটি যদি ডেটাবেস থেকে এনে ফেরত দেওয়া হয়, রহিম করিমের নাম, ঠিকানা আর ফোন নম্বর দেখে ফেললেন। এই ভুলের নাম broken object level authorization (BOLA, পুরোনো নাম IDOR). OWASP-এর API-নিরাপত্তার আলাদা তালিকায় এটি প্রথমে। Spring Security এটা নিজে ধরতে পারে না, কারণ কোন অর্ডার কার, তা শুধু আপনার ডেটা জানে।

public interface OrderRepository extends JpaRepository<Order, Long> {
    Optional<Order> findByIdAndCustomerPhone(long id, String customerPhone);
}

@Service
public class OrderService {
    private final OrderRepository orders;
    public OrderService(OrderRepository orders) { this.orders = orders; }

    @Transactional(readOnly = true)
    public OrderResponse getMyOrder(long orderId, Authentication auth) {
        return orders.findByIdAndCustomerPhone(orderId, auth.getName())   // মালিকানা query-তেই
                .map(OrderResponse::from)
                .orElseThrow(() -> new OrderNotFoundException(orderId));  // অন্যের অর্ডার → 404
    }
}

// controller: Spring নিজেই Authentication parameter-এ বর্তমান ব্যবহারকারীকে দেয়
@GetMapping("/{id}")
public OrderResponse get(@PathVariable long id, Authentication auth) {
    return service.getMyOrder(id, auth);
}

তিনটি সিদ্ধান্ত লক্ষ করুন। মালিকানার শর্ত query-র ভেতরেই — “এই id আর এই মালিকের অর্ডার” — তাই ভুলে যাচাই বাদ পড়ার সুযোগ কম। পরিচয় আসে Authentication থেকে, URL বা JSON থেকে নয়। আর অন্যের অর্ডারে 403-এর বদলে 404, যাতে রহিম জানতেই না পারেন যে ১০০২ নম্বর অর্ডার আছে। সরল ক্ষেত্রে @PreAuthorize("#phone == authentication.name")-এর মতো expression-ও চলে।

৭ · CSRF, CORS আর security header — ব্রাউজারের তিনটি নিয়ম

এই তিনটিই ব্রাউজারের আচরণের সাথে জড়িত। মোবাইল অ্যাপ বা curl ব্রাউজার নয় — এটা মাথায় রাখলেই অনেক বিভ্রান্তি কাটে।

CSRF — ব্রাউজার যখন নিজে থেকে cookie পাঠায়

কোনো সাইটের cookie থাকলে ব্রাউজার সেই সাইটে যাওয়া প্রতিটি request-এ cookie-টি নিজে থেকে জুড়ে দেয় — request কোন পাতা থেকে শুরু হলো, তা না দেখেই। তাই দোকানে লগইন করা অবস্থায় অন্য কোনো ক্ষতিকর পাতা খুললে, সেই পাতা আপনার অজান্তে দোকানে request পাঠাতে পারে, আর তাতে আপনার session cookie যাবে। এই ঝুঁকির নাম CSRF (Cross-Site Request Forgery):

shop.example.com-এ লগইন
ব্রাউজারে cookie:  SESSION=a1b2…  (HttpOnly)
এই সাইটে যাওয়া প্রতিটি request-এ ব্রাউজার এটা নিজে জুড়ে দেয়

অন্য ট্যাবে একটি অপরিচিত পাতা খোলা হলো
পাতাটি লুকিয়ে shop.example.com-এ একটি
অবস্থা-বদলানো request পাঠায়
ব্রাউজার: Cookie: SESSION=a1b2… জুড়ে দিল

Spring: এই request-এ CSRF token কোথায়?
আসল পাতা প্রতিটি ফর্মে একটি গোপন token দেয়
অন্য সাইট সেই token পড়তে পারে না
→ token নেই বা ভুল → 403

মোবাইল অ্যাপ / SPA: Authorization: Bearer eyJ…
ব্রাউজার এই header নিজে থেকে কখনো জোড়ে না
অন্য পাতার request-এ পরিচয়ই থাকে না → 401
তাই এখানে CSRF token বাড়তি সুরক্ষা দেয় না

CORS — কোন ওয়েবসাইট আপনার API ডাকতে পারবে

পর্ব ৫১-এ দেখেছেন, CORS ব্রাউজারের নিয়ম: shop.example.com-এর পাতা api.example.com-এর উত্তর পড়তে পারে শুধু তখনই, যখন API header দিয়ে অনুমতি দেয়। মনে রাখুন, CORS আপনার সার্ভারকে curl বা অন্য প্রোগ্রাম থেকে রক্ষা করে না — ওটা authentication-এর কাজ। Spring Security থাকলে CORS-এর কনফিগারেশন security chain-কেও জানাতে হয় (http.cors(...), ওপরের কনফিগারেশনে আছে), কারণ ব্রাউজারের preflight OPTIONS request-এ token থাকে না, আর security filter আগে চলে:

@Bean
CorsConfigurationSource corsConfigurationSource() {
    var cfg = new CorsConfiguration();
    cfg.setAllowedOrigins(List.of("https://shop.example.com"));     // নির্দিষ্ট origin, "*" নয়
    cfg.setAllowedMethods(List.of("GET", "POST", "PUT", "DELETE"));
    cfg.setAllowedHeaders(List.of("Authorization", "Content-Type"));
    var source = new UrlBasedCorsConfigurationSource();
    source.registerCorsConfiguration("/api/**", cfg);
    return source;
}

cookie-সহ request-এর অনুমতি (setAllowCredentials(true)) দিলে origin-এ "*" দেওয়া যায় না — Spring নিজেই error দেয়, কারণ সেটা মানে পৃথিবীর যেকোনো সাইটকে আপনার ব্যবহারকারীর পরিচয় নিয়ে API ডাকতে দেওয়া।

security header — ব্রাউজারকে বাড়তি নির্দেশ

Spring Security ডিফল্টে প্রতিটি উত্তরে কয়েকটি security header বসায় (অংশ ৩-এর curl-এর উত্তরে দেখেছেন)। এগুলো বন্ধ করবেন না:

HTML পাতা দেখানো সাইটে একটি Content-Security-Policy header যোগ করা ভালো — কোন উৎসের script চলতে পারবে, তার তালিকা। এটা সাইটভেদে আলাদা, তাই ডিফল্টে নেই; http.headers(h -> h.contentSecurityPolicy(...)) দিয়ে নিজে দিতে হয়।

৮ · কোডের বাইরের নিরাপত্তা — secret, HTTPS, log, চেষ্টার সীমা, dependency আর টেস্ট

secret কোডে নয়

JWT-এর স্বাক্ষরের key, ডেটাবেসের পাসওয়ার্ড, Google-এর client secret — এগুলো git-এ গেলে, এমনকি পরে মুছে ফেললেও, history-তে থেকে যায়। পর্ব ৫০-এ দেখেছেন, properties-এ শুধু নাম রাখুন, মান আসবে environment variable বা ক্লাউডের secret manager থেকে:

app.jwt.secret=${JWT_SECRET}                  # সার্ভারে environment variable, কোডে কখনো নয়
spring.datasource.password=${DB_PASSWORD}

HS256-এর key অন্তত ২৫৬ bit (৩২ byte) random হতে হবে — “secret123” নয়। key ফাঁস হলে মুছে দেওয়া যথেষ্ট নয়; সঙ্গে সঙ্গে নতুন key বসান (key rotation) — এতে পুরোনো সব token অবৈধ হয়ে যায়, সেটাই চাই। ডেটাবেসের ব্যবহারকারীকেও least privilege দিন: অ্যাপের ব্যবহারকারী টেবিলে পড়া-লেখা করবে, টেবিল মুছতে পারবে না।

সব জায়গায় HTTPS

HTTPS ছাড়া token, পাসওয়ার্ড আর cookie পথে খোলা লেখায় যায় — একই ক্যাফের Wi-Fi-তে থাকা কেউ পড়ে ফেলতে পারে। আসল সার্ভারে HTTP-র request HTTPS-এ ফেরত পাঠান, HSTS চালু রাখুন, cookie-তে Secure দিন। HTTPS load balancer-এ শেষ হলে Spring-কে server.forward-headers-strategy দিয়ে সেটা জানাতে হয়।

নিরাপত্তার ঘটনা log করুন — secret ছাড়া

কেউ রাত তিনটায় একটি অ্যাকাউন্টে পাঁচশোবার ভুল পাসওয়ার্ড দিলে আপনি জানতে চাইবেন। তাই log করুন: সফল ও ব্যর্থ লগইন, 403, পাসওয়ার্ড বদল, ADMIN-এর প্রতিটি দাম বদল — কে, কখন, কোন IP থেকে। Spring লগইনের event প্রকাশ করে, @EventListener দিয়ে শোনা যায়। কিন্তু log-এ কখনো নয়: পাসওয়ার্ড, token, OTP, PIN, পুরো কার্ড নম্বর; ফোন নম্বর আংশিক ঢেকে দিন। log অনেক মানুষ আর টুলের হাতে যায়, সেখানে secret গেলে সেটা আর secret থাকে না — এটাও এক ধরনের information disclosure. আর ব্যবহারকারীর লেখা log-এ বসানোর আগে নতুন লাইনের অক্ষর সরিয়ে দিন, যাতে কেউ নকল log-লাইন ঢোকাতে না পারে।

চেষ্টার সীমা

লগইন, OTP পাঠানো আর পাসওয়ার্ড ভোলার endpoint-এ rate limiting জরুরি। দুই দিক থেকে সীমা দিন: একটি অ্যাকাউন্টে (যেমন ১৫ মিনিটে ৫টি ভুল) আর একটি IP থেকে। প্রতিটি ব্যর্থতার পর অপেক্ষার সময় বাড়ান। দীর্ঘ সময় অ্যাকাউন্ট তালাবদ্ধ করার উল্টো বিপদ আছে — যে কেউ ইচ্ছা করে ভুল পাসওয়ার্ড দিয়ে আসল মালিককে আটকে রাখতে পারে; তাই সাময়িক বিরতি বা CAPTCHA প্রায়ই ভালো। সীমা পার হলে 429 Too Many Requests. Spring Security-তে এর জন্য তৈরি কিছু নেই; সাধারণত API gateway বা Bucket4j-এর মতো লাইব্রেরি এই কাজ করে।

dependency হালনাগাদ রাখুন

আপনার কোড নিখুঁত হলেও লাইব্রেরিতে ত্রুটি থাকতে পারে। পর্ব ৪৬-এ Log4Shell (২০২১) আর software supply chain-এর কথা দেখেছেন; ২০২২ সালে Spring Framework-এও “Spring4Shell” নামে পরিচিত একটি গুরুতর ত্রুটি পাওয়া যায়। তাই Spring Boot-এর patch সংস্করণ নিয়মিত হালনাগাদ করুন, Dependabot বা OWASP Dependency-Check দিয়ে জানা CVE খুঁজুন, আর অপ্রয়োজনীয় dependency বাদ দিন।

নিরাপত্তার টেস্ট — 401, 403, 200 প্রমাণ করুন

“কোড পড়ে মনে হচ্ছে ঠিক আছে” নিরাপত্তার জন্য যথেষ্ট নয়। spring-security-test যোগ করলে MockMvc-এ নকল ব্যবহারকারী বসানো যায় — @WithMockUser:

@WebMvcTest(ProductController.class)
@Import(ApiSecurityConfig.class)                      // নিজের security নিয়মগুলো টেস্টে আনুন
class PriceSecurityTest {
    @Autowired MockMvc mvc;
    @MockitoBean ProductService service;              // Spring Boot 3.4-এর আগে: @MockBean
    @MockitoBean JwtDecoder jwtDecoder;               // আসল authorization server লাগবে না

    MockHttpServletRequestBuilder changePrice() {
        return put("/api/v1/products/7/price").contentType(MediaType.APPLICATION_JSON).content("{\"price\":440}");
    }

    @Test void anyoneCanBrowse() throws Exception {
        mvc.perform(get("/api/v1/products")).andExpect(status().isOk());
    }
    @Test void anonymousGets401() throws Exception {
        mvc.perform(changePrice()).andExpect(status().isUnauthorized());
    }
    @Test @WithMockUser(roles = "CUSTOMER")
    void customerGets403() throws Exception {
        mvc.perform(changePrice()).andExpect(status().isForbidden());
    }
    @Test @WithMockUser(roles = "ADMIN")
    void adminGets200() throws Exception {
        mvc.perform(changePrice()).andExpect(status().isOk());
    }
}

প্রত্যাশিত ফল — সংস্করণভেদে আলাদা: চারটি টেস্টই পাস। কেউ পরে ভুল করে নিয়মের ক্রম বদলালে বা permitAll বসালে customerGets403 লাল হবে — ঠিক সেটাই চাই। ownership-এর জন্যও টেস্ট লিখুন: “গ্রাহক ক অন্য গ্রাহক খ-এর অর্ডার চাইলে 404”. CSRF চালু থাকা অ্যাপে অবস্থা-বদলানো request-এ .with(csrf()) যোগ করতে হয়, আর JWT-এর জন্য .with(jwt())-ও আছে।

৯ · AI-এর যুগে — AI-এর লেখা security কোড যাচাই

AI-কে “Spring Boot-এ JWT login বানাও” বললে কয়েক সেকেন্ডে কোড আসে, আর প্রায়ই সেটা চলে। কিন্তু নিরাপত্তার কোডে “চলে” মানে কিছুই প্রমাণ হয় না — সব দরজা খোলা রাখলেও অ্যাপ “চলে”। AI-এর লেখা security কোডে বারবার যে ভুলগুলো দেখা যায়:

AI-এর লেখা security কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• কোথাও "/**"-এ permitAll নেই; anyRequest() সবার শেষে আর authenticated() বা আরও কড়া
• WebSecurityConfigurerAdapter, antMatchers, authorizeRequests নেই
• পাসওয়ার্ড শুধু PasswordEncoder দিয়ে; ডেটাবেসে {bcrypt} বা {argon2} দিয়ে শুরু হওয়া লেখা
• কোডে বা git history-তে কোনো key, পাসওয়ার্ড বা client secret নেই
• CSRF বন্ধ থাকলে নিশ্চিত হয়েছি যে পরিচয় cookie-তে যায় না; CORS-এ নির্দিষ্ট origin
• প্রতিটি “আমার …” endpoint-এ ownership check আছে, আর পরিচয় আসে Authentication থেকে, request body থেকে নয়
• 401, 403, 200 আর অন্যের ডেটায় 404 — চারটির টেস্ট আছে আর পাস করে