@sun-asterisk/sunlint 1.3.39 → 1.3.41

package/skill-assets/sunlint-code-quality/rules/kotlin/S034-host-prefix-cookie.md

@@ -0,0 +1,50 @@
+---
+title: Use __Host- Prefix For Cookies
+impact: MEDIUM
+impactDescription: locks the cookie to the specific domain and path, preventing subdomain cookie tossing attacks
+tags: cookies, prefix, domain, security, kotlin
+---
+
+## Use __Host- Prefix For Cookies
+
+The `__Host-` prefix is a browser-enforced security mechanism. When a cookie name starts with `__Host-`, the browser will only accept it if it meets strict criteria, making it much harder for an attacker on a subdomain (e.g., `attacker.example.com`) to overwrite or spoof cookies for the main domain (`example.com`).
+
+**Incorrect (standard session cookie):**
+
+```kotlin
+// VULNERABLE to subdomain shadowing/tossing
+val cookie = Cookie("session_id", token).apply {
+    isHttpOnly = true
+    isSecure = true
+    path = "/"
+}
+```
+
+**Correct (__Host- prefixed cookie):**
+
+```kotlin
+// STRONGLY SECURE
+val cookie = Cookie("__Host-session_id", token).apply {
+    isHttpOnly = true
+    isSecure = true // REQ: Must be secure
+    path = "/"      // REQ: Must be /
+    // REQ: Must NOT call setDomain(). 
+    // This locks it to the EXACT host that sent it.
+}
+response.addCookie(cookie)
+
+// Ktor:
+call.sessions.set("__Host-session", MySession(token))
+// Ensure the session cookie configuration has path = "/" and secure = true
+```
+
+**__Host- Prefix Requirements:**
+1.  Must have the `Secure` flag.
+2.  Must be sent from a secure origin (HTTPS).
+3.  Must have `Path=/`.
+4.  Must **NOT** have a `Domain` attribute (this ensures it's only sent to the host that set it, not subdomains).
+
+**Why use it?**
+It prevents "Cookie Tossing" attacks where an attacker controlling a subdomain (like `blog.company.com`) sets a cookie for the parent domain (`company.com`), potentially hijacking its sessions or triggering CSRF.
+
+**Tools:** OWASP ZAP, Browser DevTools, Snyk, Manual Review

package/skill-assets/sunlint-code-quality/rules/kotlin/S035-app-hostnames.md

@@ -0,0 +1,59 @@
+---
+title: Host Apps On Different Hostnames
+impact: MEDIUM
+impactDescription: enforces origin isolation to prevent cross-app data and session leakage
+tags: hostname, isolation, same-origin, security, kotlin
+---
+
+## Host Apps On Different Hostnames
+
+Hosting multiple separate applications (e.g., a customer portal and an admin dashboard) on the same hostname but different paths (e.g., `/app` and `/admin`) is risky. Because they share the same origin, they also share cookies, `localStorage`, `sessionStorage`, and `IndexedDB`.
+
+**Incorrect (Shared Hostname):**
+```text
+https://company.com/portal  <-- Shared cookies/storage
+https://company.com/admin   <-- Shared cookies/storage
+https://company.com/blog    <-- A vulnerability in the blog can steal admin cookies!
+```
+
+**Correct (Separate Hostnames):**
+```text
+https://portal.company.com  <-- Isolated
+https://admin.company.com   <-- Isolated
+https://blog.company.com    <-- Isolated
+```
+
+**Implementation in Kotlin (CORS):**
+When applications are on different hostnames, you must configure Cross-Origin Resource Sharing (CORS) to allow them to communicate safely.
+
+```kotlin
+// Ktor CORS configuration for separate origins
+install(CORS) {
+    allowHost("portal.company.com", schemas = listOf("https"))
+    allowHost("admin.company.com", schemas = listOf("https"))
+    allowCredentials = true
+    allowHeader(HttpHeaders.Authorization)
+    allowMethod(HttpMethod.Options)
+    allowMethod(HttpMethod.Post)
+}
+
+// Spring Security
+@Bean
+fun corsConfigurationSource(): CorsConfigurationSource {
+    val configuration = CorsConfiguration()
+    configuration.allowedOrigins = listOf("https://portal.company.com")
+    configuration.allowedMethods = listOf("GET", "POST", "PUT", "DELETE")
+    configuration.allowCredentials = true
+    val source = UrlBasedCorsConfigurationSource()
+    source.registerCorsConfiguration("/**", configuration)
+    return source
+}
+```
+
+**Benefits of Isolation:**
+- **Cookie Security:** Admin session cookies cannot be read or overwritten by logic in the user portal.
+- **Storage Security:** Sensitive data in `localStorage` is scoped only to the specific application.
+- **CSRF Mitigation:** Attacking one app from another becomes much harder as they are seen as different origins.
+- **Blast Radius:** A XSS vulnerability in a less-secure part of the site (like a blog or forum) cannot easily pivot to the highly-sensitive admin panel.
+
+**Tools:** DNS Configuration, Load Balancer (NGINX/Cloudfront), Browser DevTools

package/skill-assets/sunlint-code-quality/rules/kotlin/S036-internal-file-paths.md

@@ -0,0 +1,61 @@
+---
+title: Use Internal Data For File Paths
+impact: CRITICAL
+impactDescription: prevents Path Traversal (LFI) attacks that allow reading sensitive system files
+tags: file-path, path-traversal, lfi, input-validation, security, kotlin
+---
+
+## Use Internal Data For File Paths
+
+User-provided input should never be used to construct file paths directly. An attacker can use sequences like `../` to escape the intended directory and access sensitive files on the server (e.g., `/etc/passwd`, database credentials, or source code).
+
+**Incorrect (user-controlled path construction):**
+
+```kotlin
+// VULNERABLE: Direct use of filename from query
+@GetMapping("/download")
+fun download(@RequestParam filename: String, response: HttpServletResponse) {
+    val file = File("/opt/app/uploads/$filename")
+    // Attacker: ?filename=../../../../etc/passwd
+    file.inputStream().use { it.copyTo(response.outputStream) }
+}
+```
+
+**Correct (validation and sanitization):**
+
+```kotlin
+import java.nio.file.Paths
+import kotlin.io.path.name
+
+@GetMapping("/download")
+fun safeDownload(@RequestParam filename: String): ResponseEntity<Resource> {
+    // 1. Sanitize: Extract ONLY the filename, ignore any path components
+    val safeName = Paths.get(filename).fileName.toString()
+    
+    // 2. Ideally: Map the filename to an internal ID or record in the DB
+    val fileRecord = fileRepository.findByOriginalNameAndUserId(safeName, currentUserId)
+        ?: throw NotFoundException("File not found")
+
+    // 3. Use a static base directory and the SANITIZED name
+    val baseDir = Paths.get("/opt/app/uploads").toAbsolutePath()
+    val filePath = baseDir.resolve(safeName).normalize()
+
+    // 4. Verify the resulting path is still inside the base directory
+    if (!filePath.startsWith(baseDir)) {
+        throw SecurityException("Invalid file path attempt")
+    }
+
+    val resource = FileUrlResource(filePath.toUri().toURL())
+    return ResponseEntity.ok()
+        .header(HttpHeaders.CONTENT_DISPOSITION, "attachment; filename=\"$safeName\"")
+        .body(resource)
+}
+```
+
+**Security Principles:**
+- **Whitelisting:** Store files with generated IDs (UUIDs) and look them up in a database.
+- **Sanitization:** Use `Paths.get(name).fileName` to strip directory components.
+- **Normalization:** Always call `.normalize()` and `.toAbsolutePath()` before checking if a path starts with your root directory.
+- **Isolation:** Run the application with a dedicated user that has minimal filesystem permissions.
+
+**Tools:** SonarQube (S2083), Semgrep, OWASP Path Traversal Cheat Sheet, Manual Review

package/skill-assets/sunlint-code-quality/rules/kotlin/S037-anti-cache-headers.md

@@ -0,0 +1,58 @@
+---
+title: Set Anti-cache Headers
+impact: MEDIUM
+impactDescription: prevents sensitive data from being cached in shared proxies or local browser caches
+tags: headers, cache, sensitive-data, security, kotlin
+---
+
+## Set Anti-cache Headers
+
+Sensitive information (like banking details, health records, or private profile info) cached in a browser or by a proxy can be retrieved by an attacker with access to the same machine or network. You must tell the browser strictly not to store this data.
+
+**Incorrect (no cache control for sensitive data):**
+
+```kotlin
+// Data returned without instructions to the browser
+@GetMapping("/api/bank-details")
+fun getDetails(): List<Transaction> {
+    return transactionService.findAll() // Might be cached by browser or CDN
+}
+```
+
+**Correct (explicit anti-cache headers):**
+
+```kotlin
+// Spring Boot (Manual in Controller)
+@GetMapping("/api/bank-details")
+fun getDetails(response: HttpServletResponse): List<Transaction> {
+    response.setHeader("Cache-Control", "no-store, no-cache, must-revalidate, private")
+    response.setHeader("Pragma", "no-cache")
+    response.setHeader("Expires", "0")
+    return transactionService.findAll()
+}
+
+// Ktor: Using CachingHeaders plugin
+install(CachingHeaders) {
+    options { _, outgoingContent ->
+        if (outgoingContent.contentType?.withoutParameters() == ContentType.Application.Json) {
+            CachingOptions(CacheControl.NoStore(CacheControl.Visibility.Private))
+        } else null
+    }
+}
+
+// Global Spring Security configuration (Applied by default)
+// http.headers().cacheControl().disable() // DO NOT DO THIS!
+```
+
+**Recommended Headers:**
+- `Cache-Control: no-store, no-cache, must-revalidate, private`
+- `Pragma: no-cache` (For compatibility with old HTTP/1.0 clients)
+- `Expires: 0` (Marking the content as immediately expired)
+
+**Critical areas to protect:**
+- User account and profile pages.
+- Authentication tokens or state.
+- Personalized dashboards or reports.
+- Administrative consoles.
+
+**Tools:** OWASP ZAP, Browser DevTools (Network tab), Qualys SSL Labs

package/skill-assets/sunlint-code-quality/rules/kotlin/S039-tls-certificate-validation.md

@@ -0,0 +1,62 @@
+---
+title: TLS Clients Must Validate Server Certificates
+impact: CRITICAL
+impactDescription: prevents Man-in-the-Middle (MitM) attacks by ensuring the server identity is authentic
+tags: tls, certificates, validation, mitm, security, kotlin
+---
+
+## TLS Clients Must Validate Server Certificates
+
+Disabling TLS certificate validation or trusting all certificates allows an attacker to intercept, read, and modify your traffic by presenting a self-signed or forged certificate. This completely bypasses the security provided by TLS.
+
+**Incorrect (disabled validation / trust-all):**
+
+```kotlin
+// DANGEROUS: Trusting all certificates in OkHttp
+val trustAllCerts = arrayOf<X509TrustManager>(object : X509TrustManager {
+    override fun checkClientTrusted(chain: Array<X509Certificate>, authType: String) {}
+    override fun checkServerTrusted(chain: Array<X509Certificate>, authType: String) {}
+    override fun getAcceptedIssuers(): Array<X509Certificate> = arrayOf()
+})
+
+// DANGEROUS: Trust-all SSL context
+val sslContext = SSLContext.getInstance("SSL").apply {
+    init(null, trustAllCerts, SecureRandom())
+}
+
+// DANGEROUS: Ignoring Hostname verification
+val hostnameVerifier = HostnameVerifier { _, _ -> true }
+```
+
+**Correct (proper validation):**
+
+```kotlin
+// 1. Default Behavior (Uses System Trust Store) - Safe
+val client = OkHttpClient() // Validates against trusted root CAs
+
+// 2. Custom CA for internal/private services
+val caInputStream: InputStream = File("internal-ca.pem").inputStream()
+val certificateFactory = CertificateFactory.getInstance("X.509")
+val ca = certificateFactory.generateCertificate(caInputStream)
+
+val keyStore = KeyStore.getInstance(KeyStore.getDefaultType()).apply {
+    load(null, null)
+    setCertificateEntry("ca", ca)
+}
+
+val trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()).apply {
+    init(keyStore)
+}
+
+val client = OkHttpClient.Builder()
+    .sslSocketFactory(sslContext.socketFactory, trustManagerFactory.trustManagers[0] as X509TrustManager)
+    .build()
+```
+
+**Security Checklist:**
+- Never use code that explicitly bypasses `checkServerTrusted`.
+- Do not return `true` from a custom `HostnameVerifier` without validation.
+- In production, ensure no "trust-all" SSL factories are instantiated.
+- For mobile apps, consider **Certificate Pinning** for high-security endpoints.
+
+**Tools:** SSLyze, Qualys SSL Labs, OWASP ZAP, Manual Review

package/skill-assets/sunlint-code-quality/rules/kotlin/S041-logout-invalidation.md

@@ -0,0 +1,71 @@
+---
+title: Invalidate Session On Logout
+impact: MEDIUM
+impactDescription: ensures logout actually terminates access and prevents session reuse
+tags: session, logout, invalidation, security, kotlin
+---
+
+## Invalidate Session On Logout
+
+If the server does not explicitly invalidate the session on logout, the session token remains valid. An attacker who has stolen the session token (e.g., via XSS or physical access) can continue using it even after the user thinks they have logged out.
+
+**Incorrect (client-only logout):**
+
+```kotlin
+// Frontend-only logout (token still valid on server!)
+fun logout() {
+    localStorage.removeItem("token")
+    navigateToLogin()
+}
+
+// Server doesn't invalidate session
+@PostMapping("/logout")
+fun logout(): ResponseEntity<Any> {
+    return ResponseEntity.ok("Success") // Session still active in Redis/DB!
+}
+```
+
+**Correct (server-side invalidation):**
+
+```kotlin
+// Spring Security (Handles most of this automatically)
+// http.logout().logoutUrl("/logout").invalidateHttpSession(true).deleteCookies("JSESSIONID")
+
+@PostMapping("/api/logout")
+fun logout(request: HttpServletRequest, response: HttpServletResponse): ResponseEntity<Any> {
+    // 1. Invalidate Session
+    request.session?.invalidate()
+    
+    // 2. If using JWT - add to a blacklist (Redis) until expiry
+    val token = extractToken(request)
+    tokenBlacklist.add(token)
+
+    // 3. Clear cookies explicitly
+    val cookie = Cookie("session", null).apply {
+        maxAge = 0
+        path = "/"
+        isHttpOnly = true
+        isSecure = true
+    }
+    response.addCookie(cookie)
+
+    // 4. Prevent Caching of sensitive data
+    response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate")
+    
+    return ResponseEntity.ok("Logged out")
+}
+
+// Ktor
+post("/logout") {
+    call.sessions.clear<UserSession>()
+    call.respond(HttpStatusCode.OK)
+}
+```
+
+**Best Practices:**
+- Always invalidate the session on the server side.
+- Clear authentication cookies with appropriate flags (`HttpOnly`, `Secure`).
+- If using stateless JWTs, maintain a short-lived blacklist for logged-out tokens.
+- Clear all sensitive data from client-side storage (`localStorage`, `sessionStorage`).
+
+**Tools:** Spring Security Logout, Ktor Sessions, Manual Audit

package/skill-assets/sunlint-code-quality/rules/kotlin/S042-long-lived-sessions.md

@@ -0,0 +1,57 @@
+---
+title: Re-authenticate For Long-lived Sessions
+impact: MEDIUM
+impactDescription: ensures continuous user identity verification and reduces the window for session hijacking
+tags: session, authentication, timeout, reauthentication, security, kotlin
+---
+
+## Re-authenticate For Long-lived Sessions
+
+Long-lived sessions (e.g., "Remember Me" for 30 days) are convenient but increase the risk that a stolen session token remains useful to an attacker for a long time. Periodic re-authentication for the entire session or specific sensitive actions ensures the original user is still in control.
+
+**Incorrect (sessions never expire or are too long without checks):**
+
+```kotlin
+// Infinite session age
+sessionConfig.cookie.maxAge = -1 
+
+// No re-authentication for critical tasks
+@PostMapping("/user/change-password")
+fun changePassword(@RequestBody req: NewPasswordReq) {
+    // Only checks if session is valid, doesn't ask for old password again
+    userService.updatePassword(currentUserId, req.newPassword)
+}
+```
+
+**Correct (periodic re-authentication and step-up auth):**
+
+```kotlin
+val SESSION_MAX_AGE_MS = 24 * 60 * 60 * 1000L // 1 day
+val REAUTH_INTERVAL_MS = 4 * 60 * 60 * 1000L  // 4 hours
+
+// Middleware/Interceptor for checking last auth time
+fun checkReauthNeeded(session: UserSession): Boolean {
+    val lastAuth = session.lastAuthenticatedAt ?: 0L
+    val now = System.currentTimeMillis()
+    
+    return (now - lastAuth) > REAUTH_INTERVAL_MS
+}
+
+// For sensitive operations (Step-up Authentication)
+@PostMapping("/user/delete-account")
+fun deleteAccount(@RequestBody request: DeleteAccountRequest) {
+    // REQUIRE the current password again, even if the session is valid
+    if (!authService.verifyPassword(currentUserId, request.currentPassword)) {
+        throw AccessDeniedException("Recent password verification required")
+    }
+    
+    userService.delete(currentUserId)
+}
+```
+
+**Best Practices:**
+- **Inactivity Timeout:** Invalidate sessions after an idle period (e.g., 30 minutes).
+- **Absolute Timeout:** Force a full logout after a fixed period (e.g., 12 or 24 hours), regardless of activity.
+- **Step-up Auth:** Require re-authentication (Password, OTP, or Biometric) for highly sensitive actions like changing security settings, financial transfers, or accessing personal info.
+
+**Tools:** Spring Security (ConcurrentSessionFilter, RememberMe), Ktor Sessions, Manual Audit

package/skill-assets/sunlint-code-quality/rules/kotlin/S044-critical-changes-reauth.md

@@ -0,0 +1,64 @@
+---
+title: Re-authenticate Before Critical Changes
+impact: HIGH
+impactDescription: prevents unauthorized sensitive operations if a session is left unattended or hijacked
+tags: authentication, critical, reauthentication, security, kotlin
+---
+
+## Re-authenticate Before Critical Changes
+
+Even if a user has an active session, critical identity or financial changes must require "fresh" authentication (typically the current password, an OTP, or a biometric check). This prevents an attacker who has hijacked a session or gained physical access to an unlocked device from taking full control of the account.
+
+**Incorrect (no confirmation for critical actions):**
+
+```kotlin
+// DANGEROUS: Deleting an account without confirming credentials
+@PostMapping("/account/delete")
+fun delete() {
+    userService.delete(currentUserId)
+}
+
+// DANGEROUS: Changing email without verification
+@PostMapping("/account/change-email")
+fun changeEmail(@RequestBody req: EmailChangeRequest) {
+    userService.updateEmail(currentUserId, req.newEmail)
+}
+```
+
+**Correct (require current password or 2FA):**
+
+```kotlin
+@PostMapping("/account/delete")
+fun delete(@RequestBody req: ConfirmationRequest) {
+    // 1. Confirm current password
+    val isValid = authService.verifyPassword(currentUserId, req.currentPassword)
+    if (!isValid) {
+        throw BadCredentialsException("Invalid password for confirmation")
+    }
+    
+    // 2. Log exactly who and when initiated this
+    logger.security("Account deletion initiated", "userId" to currentUserId)
+    
+    userService.delete(currentUserId)
+}
+
+// For systems with 2FA
+@PostMapping("/account/change-email")
+fun changeEmail(@RequestBody req: EmailChangeRequest) {
+    // Require TOTP/SMS code for sensitive changes
+    if (!mfaService.verifyCode(currentUserId, req.totpCode)) {
+        throw AccessDeniedException("Valid multi-factor authentication code required")
+    }
+    
+    userService.updateEmail(currentUserId, req.newEmail)
+}
+```
+
+**Actions requiring re-authentication:**
+- Changing passwords or security questions.
+- Updating email addresses or MFA settings.
+- Account deletion or deactivation.
+- Modifying linked bank accounts or credit cards.
+- Transferring large sums of money.
+
+**Tools:** Spring Security (Step-up Auth), Ktor Auth, Manual Review, OWASP ASVS

package/skill-assets/sunlint-code-quality/rules/kotlin/S045-brute-force-protection.md

@@ -0,0 +1,64 @@
+---
+title: Implement Brute-force Protection
+impact: HIGH
+impactDescription: prevents automated password guessing and account harvesting attacks
+tags: brute-force, rate-limiting, authentication, security, kotlin
+---
+
+## Implement Brute-force Protection
+
+Authentication endpoints without rate limiting or lockout mechanisms are vulnerable to brute-force attacks, where attackers try thousands of common passwords or perform "credential stuffing" attacks using stolen credentials.
+
+**Incorrect (no protection):**
+
+```kotlin
+@PostMapping("/login")
+fun login(@RequestBody data: LoginRequest): ResponseEntity<Any> {
+    val result = authService.authenticate(data.username, data.password)
+    // No limit on attempts. Attacker can call this 10,000 times a minute.
+    return ResponseEntity.ok(result)
+}
+```
+
+**Correct (rate limiting and account lockout):**
+
+```kotlin
+// Using Ktor RateLimiting
+install(RateLimit) {
+    register(RateLimitName("login")) {
+        rateLimiter(limit = 5, refillPeriod = 15.minutes)
+    }
+}
+
+// In-code tracking and exponential backoff
+class LoginService(private val redisTemplate: RedisTemplate<String, Int>) {
+    fun handleLogin(username: String) {
+        val attempts = redisTemplate.get("login_attempts:$username") ?: 0
+        
+        if (attempts >= 5) {
+            val lockoutMinutes = Math.pow(2.0, (attempts - 5).toDouble()).toLong()
+            throw LockedException("Account locked for $lockoutMinutes minutes")
+        }
+        
+        try {
+            authenticate(username)
+            redisTemplate.delete("login_attempts:$username")
+        } catch (e: Exception) {
+            redisTemplate.increment("login_attempts:$username")
+            throw e
+        }
+    }
+}
+
+// Spring Security Configuration
+// Use standard LoginFailureHandler to increment counters.
+```
+
+**Brute-Force Protection Strategies:**
+- **Rate Limiting:** Limit requests by IP and by username.
+- **Account Lockout:** Temporarily disable accounts after X failed attempts.
+- **Exponential Backoff:** Increase the wait time between successive login attempts.
+- **CAPTCHA:** Use CAPTCHA challenges after a few failed attempts.
+- **WAF:** Use a Web Application Firewall to block high-frequency attacks.
+
+**Tools:** Spring Security (LoginFailureHandler), Redis, Ktor RateLimit, Cloudflare WAF, reCAPTCHA

package/skill-assets/sunlint-code-quality/rules/kotlin/S047-oauth-csrf-protection.md

@@ -0,0 +1,74 @@
+---
+title: Protect OAuth Code Flow Vs CSRF
+impact: HIGH
+impactDescription: prevents attackers from stealing authorization codes or linking victim accounts to attacker credentials
+tags: oauth, csrf, state, authorization, security, kotlin
+---
+
+## Protect OAuth Code Flow Vs CSRF
+
+During an OAuth 2.0 Authorization Code flow, an attacker can perform a CSRF attack to force a user to link their session with the attacker's account, or to intercept the victim's authorization code. Using a `state` parameter is the standard defense.
+
+**Incorrect (no state parameter):**
+
+```kotlin
+// VULNERABLE: Initiating OAuth without a unique state
+get("/auth/google") {
+    val googleAuthUrl = "https://accounts.google.com/oauth/authorize?" +
+        "client_id=$clientId&" +
+        "redirect_uri=$redirectUri&" +
+        "response_type=code&" +
+        "scope=email"
+    call.respondRedirect(googleAuthUrl)
+}
+```
+
+**Correct (state parameter validation):**
+
+```kotlin
+import java.security.SecureRandom
+import java.util.Base64
+
+@GetMapping("/auth/google")
+fun initiateGoogleAuth(session: HttpSession, response: HttpServletResponse) {
+    // 1. Generate a random, unpredictable state
+    val state = ByteArray(32).let {
+        SecureRandom().nextBytes(it)
+        Base64.getUrlEncoder().withoutPadding().encodeToString(it)
+    }
+
+    // 2. Store it in the user's session
+    session.setAttribute("oauth_state", state)
+
+    // 3. Include it in the authorization request
+    val authUrl = "https://accounts.google.com/oauth/authorize?" +
+        "client_id=$clientId&" +
+        "redirect_uri=$redirectUri&" +
+        "response_type=code&" +
+        "state=$state"
+    
+    response.sendRedirect(authUrl)
+}
+
+@GetMapping("/auth/google/callback")
+fun handleGoogleCallback(@RequestParam code: String, @RequestParam state: String, session: HttpSession) {
+    // 4. Validate the state returned by the provider
+    val savedState = session.getAttribute("oauth_state") as? String
+    
+    if (savedState == null || savedState != state) {
+        throw AccessDeniedException("Invalid OAuth state parameter. Potential CSRF attack.")
+    }
+
+    // 5. Clear the state once used
+    session.removeAttribute("oauth_state")
+
+    // Proceed to exchange code for tokens...
+}
+```
+
+**Best Practices:**
+- Always use a random, high-entropy `state` value.
+- Store the state in a secure, server-side session or an encrypted, `HttpOnly` cookie.
+- Alternatively, use **PKCE (Proof Key for Code Exchange)** for public clients (like mobile apps), which provides even stronger protection against code interception.
+
+**Tools:** Spring Security OAuth2 (handles state automatically), Ktor Authentication, Manual Review