@sun-asterisk/sunlint 1.3.39 → 1.3.41

package/skill-assets/sunlint-code-quality/rules/java/S029-csrf-protection.md

@@ -0,0 +1,35 @@
+---
+title: Apply CSRF Protection
+impact: HIGH
+impactDescription: prevents Cross-Site Request Forgery attacks that could execute actions on behalf of the user
+tags: csrf, security, java
+---
+
+## Apply CSRF Protection
+
+CSRF attacks trick a logged-in user into sending a request to your application (e.g., via a hidden form on a malicious site). If the application relies only on cookies for authentication, the browser will include them, and the attack will succeed.
+
+**Incorrect (no CSRF protection):**
+
+```java
+// VULNERABLE: Spring Security disabled CSRF
+http.csrf(csrf -> csrf.disable());
+```
+
+**Correct (enabled and configured CSRF):**
+
+```java
+// 1. Spring Security (Enabled by default)
+// For SPAs (Stateless/JWT):
+// http.csrf(csrf -> csrf.csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()));
+
+// 2. In Thymeleaf forms (automatic token insertion):
+// <form th:action="@{/logout}" method="post">
+```
+
+**Defense Strategies:**
+- **Synchronizer Token Pattern:** Include a random token in every state-changing request (POST, PUT, DELETE).
+- **SameSite Cookie Attribute:** Set `SameSite=Lax` or `Strict`.
+- **Custom Headers:** For AJAX requests, require a custom header (e.g., `X-Requested-With`) which cannot be added cross-site without CORS permission.
+
+**Tools:** Spring Security, OWASP ZAP

package/skill-assets/sunlint-code-quality/rules/java/S030-directory-browsing.md

@@ -0,0 +1,38 @@
+---
+title: Disable Directory Browsing
+impact: MEDIUM
+impactDescription: prevents attackers from seeing the directory structure and identifying sensitive files
+tags: configuration, server, directory-browsing, security, java
+---
+
+## Disable Directory Browsing
+
+If directory browsing is enabled, an attacker visiting a folder without an `index.html` file can see all files in that directory. This often leads to the discovery of sensitive configuration files, source code backups, or uploaded data.
+
+**How to Disable:**
+
+**1. In Embedded Tomcat (Spring Boot):**
+It is disabled by default. Do not change the `server.tomcat.basedir` to a public-facing path without index files.
+
+**2. In Standard `web.xml` (Legacy):**
+```xml
+<servlet>
+    <servlet-name>default</servlet-name>
+    <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
+    <init-param>
+        <param-name>listings</param-name>
+        <param-value>false</param-value> <!-- SECURE: Set to false -->
+    </init-param>
+</servlet>
+```
+
+**3. Using Spring Security:**
+```java
+// Prevent direct access to static resource directories
+http.authorizeHttpRequests(auth -> auth
+    .requestMatchers("/static/**").permitAll()
+    .requestMatchers("/config/**").denyAll()
+);
+```
+
+**Tools:** OWASP ZAP, Manual Review

package/skill-assets/sunlint-code-quality/rules/java/S031-secure-cookie-flag.md

@@ -0,0 +1,38 @@
+---
+title: Set Secure Flag On Session Cookies
+impact: HIGH
+impactDescription: prevents cookies from being sent over unencrypted HTTP connections
+tags: cookie, secure, session, transport, security, java
+---
+## Set Secure Flag On Session Cookies
+
+The `Secure` flag ensures that the browser only sends the cookie over encrypted (HTTPS) connections. Without this flag, a cookie could be sent over a plain HTTP link (e.g., if a user manually types `http://...`), making it vulnerable to interception.
+
+**Incorrect (insecure cookie):**
+
+```java
+// VULNERABLE: Cookie can be sent over HTTP
+Cookie cookie = new Cookie("SESSION_ID", "12345");
+cookie.setPath("/");
+response.addCookie(cookie);
+```
+
+**Correct (secure cookie):**
+
+```java
+// 1. Manual Servlet API
+Cookie cookie = new Cookie("SESSION_ID", "12345");
+cookie.setSecure(true); // SECURE: Only send over HTTPS
+cookie.setPath("/");
+response.addCookie(cookie);
+
+// 2. Spring Boot Configuration (application.properties)
+// server.servlet.session.cookie.secure=true
+
+// 3. Spring Security Header
+// http.headers(headers -> headers
+//     .contentSecurityPolicy(csp -> csp.policyDirectives("upgrade-insecure-requests"))
+// );
+```
+
+**Tools:** OWASP ZAP, Browser DevTools, SonarQube (S2255)

package/skill-assets/sunlint-code-quality/rules/java/S032-httponly-cookie.md

@@ -0,0 +1,31 @@
+---
+title: Set HttpOnly On Session Cookies
+impact: HIGH
+impactDescription: prevents client-side scripts from accessing the cookie, mitigating XSS impacts
+tags: cookie, httponly, session, xss, security, java
+---
+## Set HttpOnly On Session Cookies
+
+The `HttpOnly` flag prevents JavaScript from accessing the cookie via `document.cookie`. This is a critical defense-in-depth measure; even if an attacker finds an XSS vulnerability, they cannot steal the session cookie.
+
+**Incorrect (accessible via JS):**
+
+```java
+// VULNERABLE: JS can read this cookie
+Cookie cookie = new Cookie("SESSION_ID", "12345");
+response.addCookie(cookie);
+```
+
+**Correct (HttpOnly cookie):**
+
+```java
+// 1. Manual Servlet API
+Cookie cookie = new Cookie("SESSION_ID", "12345");
+cookie.setHttpOnly(true); // SECURE: Inaccessible to JavaScript
+response.addCookie(cookie);
+
+// 2. Spring Boot Configuration (application.properties)
+// server.servlet.session.cookie.http-only=true
+```
+
+**Tools:** Browser DevTools, SonarQube (S3330)

package/skill-assets/sunlint-code-quality/rules/java/S033-samesite-cookie.md

@@ -0,0 +1,42 @@
+---
+title: Set SameSite On Session Cookies
+impact: MEDIUM
+impactDescription: prevents Cross-Site Request Forgery (CSRF) attacks by restricting cookie transmission
+tags: cookie, samesite, csrf, security, java
+---
+## Set SameSite On Session Cookies
+
+The `SameSite` attribute tells the browser whether to send the cookie with cross-site requests. Setting it to `Lax` or `Strict` significantly reduces the risk of CSRF attacks.
+
+**Incorrect (no SameSite attribute):**
+
+```java
+// VULNERABLE: Browser defaults vary, might allow cross-site sending
+Cookie cookie = new Cookie("SESSION_ID", "12345");
+response.addCookie(cookie);
+```
+
+**Correct (SameSite Lax/Strict):**
+
+```java
+// 1. Spring Boot Configuration (Recommended)
+// server.servlet.session.cookie.same-site=lax
+
+// 2. Spring Security (if using SessionRepository)
+// @Bean
+// public CookieSerializer cookieSerializer() {
+//     DefaultCookieSerializer serializer = new DefaultCookieSerializer();
+//     serializer.setSameSite("Lax");
+//     return serializer;
+// }
+
+// 3. Manual Header (Servlet 6.0+ or via Filter)
+response.setHeader("Set-Cookie", "SESSION_ID=12345; Secure; HttpOnly; SameSite=Lax");
+```
+
+**Modes:**
+- `Strict`: Cookie only sent for first-party requests.
+- `Lax`: Cookie sent for first-party and safe top-level navigations (links). **Recommended default.**
+- `None`: Cookie sent always (requires `Secure` attribute).
+
+**Tools:** OWASP ZAP, Browser DevTools

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

@@ -0,0 +1,35 @@
+---
+title: Use __Host- Prefix For Cookies
+impact: MEDIUM
+impactDescription: prevents cookie tossing and domain-shadowing attacks
+tags: cookie, host-prefix, security, java
+---
+
+## Use __Host- Prefix For Cookies
+
+The `__Host-` prefix on a cookie name provides maximum security. It forces the cookie to be `Secure`, have no specified `Domain` (preventing subdomains from accessing it), and be restricted to the same path that set it (`/`).
+
+**Incorrect (standard cookie name):**
+
+```java
+// VULNERABLE: Can be shadowed by subdomains
+Cookie cookie = new Cookie("SESSION_ID", "12345");
+```
+
+**Correct (__Host- prefix):**
+
+```java
+// SECURE: Browser enforces Secure, Path=/, and no Domain
+Cookie cookie = new Cookie("__Host-SESSION_ID", "12345");
+cookie.setSecure(true);
+cookie.setPath("/");
+response.addCookie(cookie);
+```
+
+**Requirements:**
+- The cookie name must start with `__Host-`.
+- The `Secure` attribute must be set.
+- The `Path` attribute must be `/`.
+- The `Domain` attribute must **NOT** be set.
+
+**Tools:** Browser DevTools, Manual Review

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

@@ -0,0 +1,23 @@
+---
+title: Host Apps On Different Hostnames
+impact: MEDIUM
+impactDescription: prevents Cross-Site Scripting (XSS) from spreading between different applications on the same domain
+tags: architecture, isolation, security, java
+---
+## Host Apps On Different Hostnames
+
+If multiple applications (e.g., `app.example.com` and `admin.example.com`) are hosted on the same domain (`example.com`) and share cookies or have permissive CORS, an XSS in one app can be used to attack the other.
+
+**Best Practice:**
+Use distinct subdomains or entirely different domains for applications with different trust levels.
+
+**Correct (Isolation):**
+- **Public Website:** `www.sun-asterisk.vn`
+- **Customer Portal:** `portal.sun-asterisk.vn`
+- **Internal Admin:** `admin-internal.sun-asterisk.vn` (or on a private VPC)
+
+**Why it matters:**
+- **Cookie Isolation:** Browsers can be configured to share cookies across subdomains.
+- **Same-Origin Policy:** Distinct origins provide a strong security boundary.
+
+**Tools:** Architecture Review

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

@@ -0,0 +1,39 @@
+---
+title: Use Internal Data For File Paths
+impact: CRITICAL
+impactDescription: prevents Path Traversal attacks (LFI/RFI)
+tags: architecture, path-traversal, security, java
+---
+## Use Internal Data For File Paths
+
+Never allow a user to specify the file name or path directly in a request (e.g., `?file=report.pdf`). Attackers can use `../` to access sensitive files like `/etc/passwd`.
+
+**Incorrect (trusting user for file path):**
+
+```java
+// VULNERABLE: Attacker input: ../../../etc/passwd
+@GetMapping("/download")
+public void download(@RequestParam String file, HttpServletResponse response) {
+    File target = new File("/var/www/uploads/" + file);
+    // ...
+}
+```
+
+**Correct (internal mapping):**
+
+```java
+// SECURE: Use a database ID and look up the internal path
+@GetMapping("/download/{id}")
+public void download(@PathVariable Long id, HttpServletResponse response) {
+    FileInfo info = fileRepo.findById(id).orElseThrow();
+    File target = new File("/var/www/uploads/" + info.getInternalStorageName());
+    // ...
+}
+
+// SECURE: Strict validation (Whitelist/Regex)
+if (!file.matches("^[a-zA-Z0-0._-]+\\.pdf$")) {
+    throw new SecurityException("Invalid filename");
+}
+```
+
+**Tools:** SonarQube (S2083), OWASP ZAP, Manual Review

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

@@ -0,0 +1,37 @@
+---
+title: Set Anti-cache Headers For Sensitive Pages
+impact: MEDIUM
+impactDescription: prevents sensitive data from being stored in browser or proxy caches
+tags: cache, headers, security, java
+---
+## Set Anti-cache Headers For Sensitive Pages
+
+Sensitive information (bank statements, health records) should not be cached on the user's computer or on intermediate proxies. If cached, another user of the same computer or network could potentially see the data.
+
+**Incorrect (cacheable sensitive data):**
+
+```java
+@GetMapping("/account/balance")
+public ResponseEntity<BalanceDto> getBalance() {
+    return ResponseEntity.ok(service.getBalance());
+}
+```
+
+**Correct (anti-cache headers):**
+
+```java
+@GetMapping("/account/balance")
+public ResponseEntity<BalanceDto> getBalance() {
+    return ResponseEntity.ok()
+        .header(HttpHeaders.CACHE_CONTROL, "no-store, no-cache, must-revalidate, max-age=0")
+        .header(HttpHeaders.PRAGMA, "no-cache")
+        .body(service.getBalance());
+}
+```
+
+**Recommended Headers:**
+- `Cache-Control: no-store, no-cache, must-revalidate, max-age=0`
+- `Pragma: no-cache`
+- `Expires: 0`
+
+**Tools:** Browser DevTools, OWASP ZAP

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

@@ -0,0 +1,43 @@
+---
+title: TLS Clients Must Validate Server Certificates
+impact: CRITICAL
+impactDescription: prevents Man-in-the-Middle (MitM) attacks by ensuring the server is authentic
+tags: tls, certificates, validation, mitm, security, java
+---
+## TLS Clients Must Validate Server Certificates
+
+Disabling certificate validation (trusting all certificates) makes TLS useless. An attacker can use a self-signed certificate to intercept and read all traffic between your client and the server.
+
+**Incorrect (disabled validation):**
+
+```java
+// VULNERABLE: Trusting all certificates
+TrustManager[] trustAllCerts = new TrustManager[]{
+    new X509TrustManager() {
+        public void checkClientTrusted(X509Certificate[] chain, String authType) {}
+        public void checkServerTrusted(X509Certificate[] chain, String authType) {}
+        public X509Certificate[] getAcceptedIssuers() { return null; }
+    }
+};
+SSLContext sc = SSLContext.getInstance("TLS");
+sc.init(null, trustAllCerts, new SecureRandom());
+```
+
+**Correct (default/strict validation):**
+
+```java
+// SECURE: Use the default JVM TrustManager (uses the system keystore)
+SSLContext sc = SSLContext.getDefault();
+
+// SECURE: Use a custom Truststore containing only your CA
+KeyStore trustStore = KeyStore.getInstance("PKCS12");
+trustStore.load(new FileInputStream("my-ca.p12"), password);
+
+TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
+tmf.init(trustStore);
+
+SSLContext sc = SSLContext.getInstance("TLS");
+sc.init(null, tmf.getTrustManagers(), new SecureRandom());
+```
+
+**Tools:** FindSecBugs (WEAK_TRUST_MANAGER), SonarQube (S4830)

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

@@ -0,0 +1,53 @@
+---
+title: Invalidate Session On Logout
+impact: CRITICAL
+impactDescription: ensures that stolen or leaked session tokens cannot be reused after a user has logged out
+tags: session, logout, invalidation, security, java
+---
+
+## Invalidate Session On Logout
+
+When a user logs out, the session must be destroyed on the server. Simply deleting the cookie on the client is insufficient, as the session remains active on the server and can be hijacked if an attacker possesses the session ID.
+
+**Incorrect (client-side only logout):**
+
+```java
+// VULNERABLE: Only deletes cookie, session still exists on server
+@GetMapping("/logout")
+public String logout(HttpServletResponse response) {
+    Cookie cookie = new Cookie("JSESSIONID", null);
+    cookie.setMaxAge(0);
+    response.addCookie(cookie);
+    return "redirect:/login";
+}
+```
+
+**Correct (server-side session invalidation):**
+
+```java
+// 1. Using Standard Servlet API
+@GetMapping("/logout")
+public String logout(HttpServletRequest request) {
+    HttpSession session = request.getSession(false);
+    if (session != null) {
+        session.invalidate(); // Destroys the session on the server
+    }
+    return "redirect:/login";
+}
+
+// 2. Using Spring Security (Recommended)
+// Configure in SecurityFilterChain:
+// http.logout(logout -> logout
+//     .logoutUrl("/auth/logout")
+//     .invalidateHttpSession(true)
+//     .deleteCookies("JSESSIONID")
+//     .logoutSuccessUrl("/login")
+// );
+```
+
+**JWT (Stateless) Logout:**
+For JWTs, since they are stateless, you cannot "invalidate" them on the server easily.
+- **Option A:** Use short-lived Access Tokens and revoke Refresh Tokens.
+- **Option B:** Maintain a "Denylist" in Redis for revoked JTI (JWT ID) claims until they expire.
+
+**Tools:** Spring Security, OWASP ZAP, Manual Audit

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

@@ -0,0 +1,36 @@
+---
+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, security, java
+---
+## Re-authenticate For Long-lived Sessions
+
+Long-lived sessions (e.g., "Remember Me" for 30 days) increase the risk of session hijacking. For sensitive actions, you should require the user to re-enter their password even if they are already "logged in."
+
+**Incorrect (never re-auth):**
+
+```java
+@PostMapping("/user/change-email")
+public void changeEmail(@RequestBody String newEmail) {
+    // VULNERABLE: If the computer was left unlocked, anyone can change the email
+    userService.updateEmail(currentUserId, newEmail);
+}
+```
+
+**Correct (fresh authentication):**
+
+```java
+@PostMapping("/user/change-email")
+public ResponseEntity<?> changeEmail(@RequestBody ChangeEmailRequest req) {
+    // SECURE: Verify the password again for this critical action
+    if (!authService.verifyPassword(currentUserId, req.getPassword())) {
+        return ResponseEntity.status(401).body("Password verification failed");
+    }
+    
+    userService.updateEmail(currentUserId, req.getNewEmail());
+    return ResponseEntity.ok().build();
+}
+```
+
+**Tools:** Spring Security (IsFullyAuthenticated), Manual Audit

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

@@ -0,0 +1,28 @@
+---
+title: Re-authenticate Before Critical Changes
+impact: HIGH
+impactDescription: prevents unauthorized sensitive operations if a session is left unattended or hijacked
+tags: authentication, reauthentication, security, java
+---
+## Re-authenticate Before Critical Changes
+
+Critical actions like changing passwords, changing emails, or deleting an account should always require a fresh authentication step (password or MFA challenge).
+
+**Correct (Spring Security):**
+
+```java
+// Use @PreAuthorize to ensure user did not use "Remember Me" for this specific method
+@PreAuthorize("isFullyAuthenticated()")
+@PostMapping("/settings/delete-account")
+public void deleteAccount() {
+    // ...
+}
+```
+
+**Definition of "Critical Changes":**
+- Security settings (MFA, password).
+- Contact information (Email, Phone).
+- Financial transactions or withdrawal.
+- Account deletion.
+
+**Tools:** Spring Security, OWASP ASVS

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

@@ -0,0 +1,38 @@
+---
+title: Implement Brute-Force Protection
+impact: HIGH
+impactDescription: prevents automated attacks from guessing passwords or credentials
+tags: brute-force, rate-limiting, authentication, security, java
+---
+## Implement Brute-Force Protection
+
+Without protection, an attacker can use automated scripts to try thousands of password combinations. You must implement rate limiting or account lockout mechanisms.
+
+**Incorrect (no protection):**
+
+```java
+@PostMapping("/login")
+public void login(@RequestBody LoginRequest req) {
+    // VULNERABLE: No limit on the number of attempts
+    boolean success = authService.authenticate(req);
+}
+```
+
+**Correct (rate limiting and lockout):**
+
+```java
+// 1. Using Bucket4j for Rate Limiting
+@PostMapping("/login")
+public ResponseEntity<?> login(@RequestBody LoginRequest req) {
+    String clientIp = getClientIp();
+    if (loginRateLimiter.tryConsume(clientIp)) {
+        // Proceed with auth
+        boolean success = authService.authenticate(req);
+        // ...
+    } else {
+        return ResponseEntity.status(429).body("Too many attempts");
+    }
+}
+```
+
+**Tools:** Bucket4j, Spring Security Lockout, Redis

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

@@ -0,0 +1,33 @@
+---
+title: Protect OAuth Code Flow Vs CSRF
+impact: HIGH
+impactDescription: prevents attackers from linking their accounts to a victim's session
+tags: oauth2, csrf, state, security, java
+---
+## Protect OAuth Code Flow Vs CSRF
+
+In the OAuth2 Authorization Code flow, you must use the `state` parameter to prevent CSRF. The `state` parameter ensures that the response from the Authorization Server (AS) matches the original request initiated by the user.
+
+**Incorrect (missing state):**
+
+```java
+// VULNERABLE: No state parameter
+String redirectUrl = "https://auth-server.com/authorize?client_id=123&response_type=code";
+```
+
+**Correct (using state):**
+
+```java
+// SECURE: Generate and verify state
+String state = generateSecureRandomString();
+session.setAttribute("oauth_state", state);
+String redirectUrl = "https://auth-server.com/authorize?client_id=123&response_type=code&state=" + state;
+
+// In the callback:
+String returnedState = request.getParameter("state");
+if (!state.equals(returnedState)) {
+    throw new SecurityException("CSRF Detected");
+}
+```
+
+**Tools:** Spring Security OAuth2 (handles this automatically)

package/skill-assets/sunlint-code-quality/rules/java/S048-oauth-redirect-validation.md

@@ -0,0 +1,25 @@
+---
+title: Validate OAuth Redirect URIs Exactly
+impact: HIGH
+impactDescription: prevents attackers from stealing authorization codes via open redirects
+tags: oauth2, redirect, validation, security, java
+---
+## Validate OAuth Redirect URIs Exactly
+
+An attacker could specify a malicious `redirect_uri` in the authorize request. If the server does not perform exact matching, the authorization code could be sent to the attacker.
+
+**Incorrect (prefix matching):**
+
+```java
+// VULNERABLE: Allows redirect to https://your-site.com.attacker.com
+if (redirectUri.startsWith("https://your-site.com")) { ... }
+```
+
+**Correct (exact matching):**
+
+```java
+// SECURE: Exact string comparison against an allow-list
+if (ALLOWED_REDIRECT_URIS.contains(redirectUri)) { ... }
+```
+
+**Tools:** Spring Security OAuth2

package/skill-assets/sunlint-code-quality/rules/java/S049-auth-code-expiry.md

@@ -0,0 +1,23 @@
+---
+title: Authentication Codes Must Expire Quickly
+impact: HIGH
+impactDescription: limits the window of opportunity for an attacker to use a stolen code
+tags: oauth2, authentication, expiry, security, java
+---
+## Authentication Codes Must Expire Quickly
+
+Authorization codes (and OTPs) are intended for immediate, one-time use. They should have a very short lifespan (typically 1 to 10 minutes).
+
+**Correct (Spring Security):**
+
+```java
+// Configure the token store or code service to expire codes
+// Default in Spring Security OAuth2 is usually 5 minutes
+```
+
+**Best Practice:**
+- Max lifespan: **10 minutes**.
+- Revoke code immediately after use (One-time use).
+- Revoke all associated tokens if a code is used twice (indicates an attack).
+
+**Tools:** Spring Security, Redis (for TTL)

package/skill-assets/sunlint-code-quality/rules/java/S050-token-entropy.md

@@ -0,0 +1,20 @@
+---
+title: Reference Tokens Entropy
+impact: HIGH
+impactDescription: ensures that tokens cannot be guessed by an attacker
+tags: tokens, entropy, csprng, security, java
+---
+## Reference Tokens Entropy
+
+Opaque reference tokens (like session IDs or API keys) must be generated using a CSPRNG and have enough entropy to prevent guessing (at least 128 bits).
+
+**Correct (SecureRandom):**
+
+```java
+SecureRandom random = new SecureRandom();
+byte[] bytes = new byte[24]; // 192 bits of entropy
+random.nextBytes(bytes);
+String token = Base64.getUrlEncoder().withoutPadding().encodeToString(bytes);
+```
+
+**Tools:** SecureRandom, SonarQube (S2245)

package/skill-assets/sunlint-code-quality/rules/java/S051-password-length.md

@@ -0,0 +1,20 @@
+---
+title: Support 12-64 Char Passwords
+impact: MEDIUM
+impactDescription: follows modern security standards for password length
+tags: password, policy, security, java
+---
+## Support 12-64 Char Passwords
+
+Restricting password length too much prevents strong passphrases. Allowing too much length without limits can lead to hashing-based DoS.
+
+**Correct (Hibernate Validator):**
+
+```java
+public class UserDto {
+    @Size(min = 12, max = 64)
+    private String password;
+}
+```
+
+**Tools:** NIST Guidelines, Hibernate Validator