Web Development

The container loads the class, creates one instance, calls init(ServletConfig) once, calls service() for every request (dispatching to doGet/doPost and so on), and calls destroy() once on shutdown or undeploy.

• Instantiation happens on first request or at startup if load-on-startup is set.
• Many request threads share the single instance, so instance fields must be thread-safe.

The container runs service() concurrently on a pool of threads against a single servlet instance. Any mutable instance or static field is shared state and needs synchronization or must be avoided.

• Keep per-request data in local variables or request attributes.
• SingleThreadModel was deprecated and removed (Servlet 6.0) because it never solved shared static/session state.

ServletConfig is per servlet (its init params). ServletContext is per web application: shared attributes, context params, resource access, and logging for all servlets.

• ServletContext attributes act as application-scoped storage, shared across all users.
• One ServletContext per application per JVM (per distributed container node).

forward and include are server-side hand-offs inside the same request via RequestDispatcher. sendRedirect sends a 302 (or chosen 3xx) to the client, which issues a new request.

• Forward: URL in the browser unchanged, same request attributes, single round trip.
• Redirect: URL changes, request attributes are lost, extra round trip; use it for Post/Redirect/Get.
• Include inserts the target output into the current response.

A Filter intercepts requests and responses before and after the servlet. doFilter(req, res, chain) runs pre-logic, calls chain.doFilter to continue, then runs post-logic on the way back.

public class TimingFilter implements Filter {
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
            throws IOException, ServletException {
        long t = System.nanoTime();
        try {
            chain.doFilter(req, res);
        } finally {
            System.out.println((System.nanoTime() - t) / 1_000_000 + " ms");
        }
    }
}

• Use cases: authentication, logging, compression, CORS, encoding.
• Not calling chain.doFilter short-circuits the request.

Filters are a servlet-container feature working on raw ServletRequest/ServletResponse before DispatcherServlet. HandlerInterceptor is a Spring MVC feature that runs inside DispatcherServlet and knows the resolved handler.

• Interceptor hooks: preHandle, postHandle, afterCompletion.
• Filters can wrap the request/response (body caching, compression); interceptors cannot replace them.
• Exceptions thrown in filters bypass @ControllerAdvice.

Listeners observe lifecycle and attribute events: ServletContextListener (app start/stop), HttpSessionListener (session created/destroyed), ServletRequestListener, and attribute listeners for context, session and request.

• Typical use: initialize connection pools or caches in contextInitialized, release them in contextDestroyed.
• HttpSessionBindingListener and HttpSessionActivationListener are implemented by the attribute values themselves.

The server creates an HttpSession holding state in memory keyed by a random ID, and sends the ID to the client in a cookie (JSESSIONID). The client returns it on each request, and the server looks the session up.

• Created lazily on request.getSession() (or getSession(true)); getSession(false) returns null if none exists.
• Idle timeout via session-timeout or setMaxInactiveInterval.
• URL rewriting (;jsessionid=) is the cookie-less fallback and should be disabled in modern apps.

HttpOnly blocks JavaScript access, Secure restricts to HTTPS, SameSite (Strict, Lax, None) limits cross-site sending, and Domain, Path, Max-Age/Expires control scope and lifetime.

• SameSite=None requires Secure.
• Browsers default to Lax when unspecified (Chrome and others).
• Session cookies should be HttpOnly; Secure; SameSite=Lax.

An attacker plants a known session ID in the victim's browser, the victim logs in, and the unchanged ID now identifies an authenticated session the attacker can reuse. Prevent by issuing a new session ID at login.

• Servlet 3.1+: request.changeSessionId(); Spring Security does this by default (changeSessionId strategy).
• Also disable URL-based session IDs and set cookie flags.

Sticky sessions, session replication, an external session store (Redis, JDBC via Spring Session), or stateless tokens.

• Sticky sessions: simplest, but node failure loses sessions and load balances unevenly.
• Replication: heavy network traffic and memory; poor scaling.
• External store: survives restarts, scales; adds a network hop and serialization cost.
• Stateless: no server state, but revocation is harder.

JSP is an HTML template with embedded Java/EL/tag libraries. The container translates each JSP into a servlet class, compiles it on first access, and executes it like any servlet.

• Lifecycle: translate, compile, jspInit, _jspService, jspDestroy.
• Scriptlets are discouraged; use EL (${user.name}) and JSTL.
• Implicit objects: request, session, application, out, pageContext.

Model holds data and business logic, View renders output, Controller handles input and chooses the view. It separates concerns so each part can change independently.

• Servlet-era: servlet as controller, JSP as view, POJOs as model.
• Spring MVC: DispatcherServlet is the front controller.

DispatcherServlet receives the request, HandlerMapping finds the handler, interceptors run preHandle, HandlerAdapter invokes the controller with resolved arguments, the return value is processed by a HttpMessageConverter (REST) or ViewResolver (views), and exceptions go to HandlerExceptionResolver.

• Argument binding: @PathVariable, @RequestParam, @RequestBody (via message converters).
• @RestController = @Controller + @ResponseBody.

Safe methods do not change server state (GET, HEAD, OPTIONS, TRACE). Idempotent methods yield the same server state when repeated (those plus PUT and DELETE). POST and PATCH are neither guaranteed.

• Idempotency is about server state, not identical responses: a repeated DELETE may return 404 the second time.
• Clients, proxies and browsers rely on these properties to retry and prefetch.

POST creates a subordinate resource or triggers processing, with a server-assigned URI. PUT fully replaces a resource at a client-known URI. PATCH applies a partial modification.

• PATCH formats: JSON Merge Patch (application/merge-patch+json) or JSON Patch (application/json-patch+json).
• PUT creates the resource if it does not exist (201) or replaces it (200/204).

1xx informational, 2xx success, 3xx redirection, 4xx client error, 5xx server error.

• 200 OK, 201 Created (with Location), 202 Accepted (async), 204 No Content.
• 301/308 permanent, 302/307 temporary redirect; 304 Not Modified.
• 400 malformed, 401 unauthenticated, 403 forbidden, 404 not found, 409 conflict, 422 semantic validation, 429 too many requests.
• 500 internal error, 502 bad gateway, 503 unavailable, 504 gateway timeout.

301 and 308 are permanent; 302 and 307 are temporary. 307 and 308 require the client to keep the method and body, while historically 301/302 allowed browsers to turn POST into GET.

• Use 303 See Other after a POST to redirect to a GET resource.
• Permanent redirects are cached aggressively by browsers.

Content-Type, Accept, Authorization, Cache-Control, ETag/If-None-Match, Location, Set-Cookie/Cookie, Origin, Content-Length/Transfer-Encoding, User-Agent, X-Forwarded-For/Forwarded.

• Content-Type describes the request body; Accept describes desired response types.
• Behind a proxy, use X-Forwarded-* (with server.forward-headers-strategy in Spring Boot) to recover client IP, scheme and host.

Cache-Control directives tell browsers and shared caches how long and whether to store a response: max-age, s-maxage, no-cache, no-store, public, private, must-revalidate, immutable.

• no-cache means store but revalidate before use; no-store means never store.
• private forbids shared caches (CDNs); use it for user-specific data.
• Fingerprinted static assets: public, max-age=31536000, immutable.

The server returns an ETag validator. The client sends it back as If-None-Match; if unchanged the server replies 304 Not Modified with no body, saving bandwidth.

• Strong ETags mean byte-identical; weak ones (W/"...") mean semantically equivalent.
• Last-Modified/If-Modified-Since is the date-based alternative.
• If-Match on PUT/DELETE gives optimistic concurrency (412 Precondition Failed on mismatch).

@GetMapping("/items/{id}")
ResponseEntity<Item> get(@PathVariable long id) {
    Item i = service.find(id);
    return ResponseEntity.ok().eTag("\"" + i.version() + "\"").body(i);
}

Client-server, stateless, cacheable, uniform interface, layered system, and optional code-on-demand. The uniform interface covers resource identification by URI, manipulation through representations, self-descriptive messages, and HATEOAS.

• Stateless: each request carries all context; the server holds no client session state.
• Resources are nouns; verbs come from HTTP methods.

It grades APIs on four levels: 0 single endpoint tunneling (RPC/POX), 1 resources with individual URIs, 2 proper HTTP verbs and status codes, 3 hypermedia controls (HATEOAS).

• Most production APIs stop at level 2.
• Level 3 embeds links (_links) so clients discover actions; Spring HATEOAS supports it.

Use plural nouns for collections, hierarchy for ownership, and HTTP methods for actions: GET /orders, GET /orders/42, GET /orders/42/items.

• Lowercase, hyphenated, no verbs, no file extensions.
• Filtering, sorting and paging go in query parameters.
• For non-CRUD actions, model a sub-resource (POST /orders/42/cancellation) rather than /cancelOrder.

The client states preferences with Accept (and Accept-Language, Accept-Encoding) using quality values, and the server picks a representation, returning 406 Not Acceptable if none matches. The request body type is declared with Content-Type, and unsupported ones yield 415.

• Spring MVC: produces/consumes on mappings select handlers by media type.
• Always send Vary: Accept when the representation depends on it.

@GetMapping(value = "/report", produces = {"application/json", "text/csv"})
Report report() { return service.report(); }

CORS lets a server tell browsers which cross-origin pages may read its responses. For non-simple requests the browser sends a preflight OPTIONS with Origin, Access-Control-Request-Method and -Headers, and the server answers with Access-Control-Allow-* headers.

• Simple requests (GET/POST with basic headers and content types) skip the preflight.
• Credentials require an explicit origin (not *) and Access-Control-Allow-Credentials: true.
• Preflight results are cached via Access-Control-Max-Age.

Cross-site request forgery makes a victim's browser send an authenticated, state-changing request because cookies are attached automatically. Defend with synchronizer or double-submit CSRF tokens, SameSite cookies, and checking Origin/Referer.

• Spring Security enables CSRF protection by default for browser flows.
• APIs authenticated with an Authorization header (not cookies) are not CSRF-prone, so it is commonly disabled for stateless APIs.

Cross-site scripting injects attacker script into pages viewed by others. Types: stored, reflected, DOM-based. Prevent with context-aware output encoding, input validation, a Content Security Policy, and HttpOnly cookies.

• Template engines (Thymeleaf th:text, JSTL <c:out>) escape by default; th:utext and raw ${} in JSP scriptlets do not.
• JSON APIs must send Content-Type: application/json plus X-Content-Type-Options: nosniff.

Strict-Transport-Security (force HTTPS), Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options or CSP frame-ancestors (clickjacking), Referrer-Policy, and Permissions-Policy.

• Spring Security adds several of these by default.
• HSTS is only honoured over HTTPS responses.

Authentication verifies who you are (credentials, token). Authorization decides what that identity may do (roles, permissions, policies).

• Failures: unauthenticated gives 401; authenticated but denied gives 403.
• Authorization models: RBAC, ABAC, ownership checks on each object.

Hash with a slow, salted, adaptive algorithm: bcrypt, scrypt, Argon2 or PBKDF2. Never encrypt reversibly and never use plain SHA-256/MD5.

• Spring Security: PasswordEncoder (BCryptPasswordEncoder, DelegatingPasswordEncoder with {bcrypt} prefixes enabling migration).
• Salt is stored with the hash; a pepper is optional and kept outside the database.

Basic sends base64 user:password in Authorization every request (needs TLS). Form login posts credentials once and then relies on a session cookie. Token auth sends a bearer token (Authorization: Bearer ...) on each request.

• Base64 is encoding, not encryption.
• Tokens suit APIs and mobile; sessions suit server-rendered apps.

A JSON Web Token is header.payload.signature, each Base64URL-encoded. The signature (HS256 shared secret, RS256/ES256 key pair) makes it tamper-evident; the payload is readable by anyone.

• Standard claims: iss, sub, aud, exp, nbf, iat, jti.
• Validate signature, algorithm whitelist, exp, iss and aud.

JWTs are self-contained so the server cannot invalidate one before exp without extra state. Mitigate with short-lived access tokens plus refresh tokens, a denylist keyed by jti, or key rotation.

• Rotate refresh tokens and detect reuse to spot theft.
• Large claims inflate every request's headers.

Roles: resource owner, client, authorization server, resource server. In the authorization code flow the client redirects the user to the authorization server, receives a one-time code at its redirect URI, and exchanges it (server-side, with client credentials or PKCE) for access and refresh tokens.

• Use PKCE for public clients (SPAs, mobile); it is recommended for all clients in OAuth 2.1.
• state parameter protects against CSRF on the callback.

Client credentials (service-to-service, no user), refresh token (renew access), device code (input-limited devices), and the deprecated password and implicit grants.

• Client credentials: the client is the resource owner; scope by service identity.
• Resource servers validate tokens by JWT signature or by introspection (RFC 7662).

Browsers send multipart/form-data. Servlet 3.0+ exposes parts via request.getParts() (@MultipartConfig); Spring wraps them as MultipartFile.

@PostMapping(value = "/files", consumes = "multipart/form-data")
ResponseEntity<Void> upload(@RequestParam("file") MultipartFile f) throws IOException {
    Path target = Path.of("/data/uploads", UUID.randomUUID().toString());
    f.transferTo(target);
    return ResponseEntity.status(201).build();
}

• Spring Boot limits: spring.servlet.multipart.max-file-size (default 1MB) and max-request-size (10MB).
• Small parts stay in memory; larger spill to temp files (file-size-threshold).

Enforce size limits, allowlist types by content inspection, rename files, store outside the web root (or in object storage), scan for malware, and serve downloads with a safe Content-Type and Content-Disposition: attachment.

• Beware zip bombs and decompression, image parser vulnerabilities, and SVG scripts.
• Do not execute or serve uploaded files from a path that runs JSP/scripts.

request.startAsync() returns an AsyncContext and releases the container thread while the work continues elsewhere. When finished, call asyncContext.complete() or dispatch() to write the response.

@WebServlet(urlPatterns = "/slow", asyncSupported = true)
public class SlowServlet extends HttpServlet {
    protected void doGet(HttpServletRequest req, HttpServletResponse res) {
        AsyncContext ctx = req.startAsync();
        ctx.setTimeout(5000);
        CompletableFuture.runAsync(() -> {
            try { ctx.getResponse().getWriter().write("done"); }
            catch (IOException e) { /* log */ }
            finally { ctx.complete(); }
        });
    }
}

• Every filter in the chain must also declare asyncSupported = true.
• Register an AsyncListener for timeouts and errors.

Return Callable, DeferredResult, CompletableFuture, StreamingResponseBody or SseEmitter from a controller. Spring starts async processing, frees the container thread, and re-dispatches when the result is ready.

• Callable runs on the MVC async executor; configure a bounded AsyncTaskExecutor (the default simple executor creates a thread per task).
• DeferredResult is completed from any thread, e.g. a message listener.

All are servlet containers that run inside the application JAR. Tomcat is the Spring Boot default and the most widely deployed; Jetty is lightweight and strong for async/WebSocket and embedding; Undertow is non-blocking-core with low memory and high throughput.

• Switch by excluding spring-boot-starter-tomcat and adding spring-boot-starter-jetty or -undertow.
• Tuning: server.tomcat.threads.max (default 200), accept-count, max-connections.
• Spring Boot 3 requires Servlet 6 (Jakarta namespace); Undertow lacks Servlet 6.1 support in Boot 3.x/4 so check compatibility.

An acceptor thread accepts sockets, poller threads watch idle keep-alive connections via NIO, and a worker thread from the executor pool handles each active request until the response completes.

• max-connections (default 8192) bounds open sockets; accept-count (default 100) is the OS backlog queue.
• Blocking servlet I/O still ties up a worker for the whole request.

Thread-per-request dedicates a thread to each request, blocking on I/O; it is simple but capacity is bounded by thread count. Reactive (WebFlux/Netty) uses a few event-loop threads with non-blocking I/O and backpressure, scaling to many concurrent slow connections.

• Reactive requires non-blocking drivers end to end (R2DBC, reactive HTTP clients); one blocking call stalls an event loop.
• Debugging and stack traces are harder; CPU-bound work gains nothing.
• Java 21 virtual threads (spring.threads.virtual.enabled=true) give thread-per-request code with high concurrency.

Java 21 virtual threads let servers run each request on a cheap JVM-managed thread, so blocking calls no longer waste OS threads. Tomcat/Jetty run requests on virtual threads when configured.

• Spring Boot 3.2+: spring.threads.virtual.enabled=true.
• Pinning: blocking inside synchronized pinned the carrier in Java 21 (largely fixed in Java 24); prefer ReentrantLock.
• Bound downstream resources (pools, semaphores) because thread count is no longer the throttle.

Common strategies: URI path (/v1/orders), header (X-API-Version), media type (application/vnd.acme.v2+json), and query parameter. Path versioning is the most visible and cache friendly; media type is purist.

• Prefer additive, backward-compatible changes; version only on breaking changes.
• Publish deprecation with Deprecation/Sunset headers and a timeline.
• Spring Framework 7 adds built-in API versioning support in MVC mappings.

Offset/page uses LIMIT n OFFSET m, which is simple but degrades on deep pages and shows duplicates or gaps when data changes. Cursor (keyset) pagination uses the last seen sort key, giving stable, constant-cost pages.

SELECT id, created_at FROM orders
WHERE (created_at, id) < (:lastCreated, :lastId)
ORDER BY created_at DESC, id DESC
LIMIT 20;

• Return nextCursor (opaque, encoded) and optionally Link headers.
• Cursors cannot jump to an arbitrary page.

Accept a Pageable argument (?page=0&size=20&sort=name,asc) and return Page<T>, which carries content plus total counts. Slice<T> skips the count query.

• Page runs an extra COUNT(*), which is costly on large tables.
• Cap spring.data.web.pageable.max-page-size (default 2000) to prevent abuse.

Common algorithms: fixed window, sliding window, token bucket and leaky bucket. Token bucket allows controlled bursts and is the most common. Enforce at the gateway or with a shared store (Redis) keyed by user, API key or IP.

• Respond 429 Too Many Requests with Retry-After and RateLimit-* headers.
• Libraries: Bucket4j, Resilience4j RateLimiter, API gateway plugins.
• Per-node in-memory limits multiply by node count in a cluster.

OpenAPI is a language-neutral specification (YAML/JSON) describing endpoints, schemas, auth and responses. Swagger UI renders it, and tools generate clients and servers from it.

• Code-first: springdoc-openapi scans Spring annotations and serves /v3/api-docs and /swagger-ui.html.
• Design-first: write the spec, generate stubs with openapi-generator, and validate contract compliance.
• Annotations like @Operation, @Schema, @ApiResponse enrich docs.

Return an appropriate status code and a consistent body. RFC 9457 (formerly 7807) Problem Details defines application/problem+json with type, title, status, detail, instance.

• Spring 6 / Boot 3: ProblemDetail and ErrorResponse, enabled via spring.mvc.problemdetails.enabled=true.
• Centralize with @RestControllerAdvice and @ExceptionHandler.
• Never leak stack traces or SQL in responses.

HTTP/1.1 reuses connections (keep-alive) but handles one request at a time per connection (head-of-line blocking). HTTP/2 multiplexes streams over one TCP connection with header compression (HPACK). HTTP/3 runs over QUIC (UDP) removing TCP-level head-of-line blocking.

• Browsers require TLS for HTTP/2 in practice; Spring Boot enables it with server.http2.enabled=true.
• HTTP/2 server push is deprecated and removed from major browsers.

Content-Length declares the body size up front. Transfer-Encoding: chunked (HTTP/1.1) sends the body in sized chunks when the length is unknown, enabling streaming. HTTP/2 uses frames instead.

• Use StreamingResponseBody, ResponseBodyEmitter or SseEmitter in Spring MVC for large or incremental output.
• Server-Sent Events use text/event-stream over a long-lived response.

This is session fixation: the session ID did not change on authentication. Rotate the ID at login.

HttpSession old = request.getSession(false);
if (old != null) {
    request.changeSessionId();   // Servlet 3.1+, keeps attributes
}

• Spring Security does this by default; custom login code often misses it.
• Also set HttpOnly, Secure, SameSite, and disable URL rewriting (<tracking-mode>COOKIE</tracking-mode>).

Sessions live in the JVM heap of the old process, so a restart drops them. Persist sessions externally (Spring Session with Redis/JDBC) or use stateless tokens.

• Tomcat can persist sessions across restarts with PersistentManager/StandardManager serialization, only when attributes are Serializable and the restart is graceful.
• Rolling deployments with sticky sessions still lose sessions of drained nodes.

Production uses a clustered or persisted session store that serializes attributes, while dev keeps them in memory. A non-Serializable object (or a field in its graph) was stored in the session.

• Fix: implement Serializable with a serialVersionUID, store only small ID/DTO values, and mark heavy fields transient.
• Never put entities, connections or streams in the session.

Take several thread dumps (jcmd <pid> Thread.print or jstack) a few seconds apart and look at what the http-nio-*-exec-* threads are doing; consistent stacks in the same frame show the bottleneck.

• Common causes: slow DB queries, exhausted connection pool (threads parked in HikariPool.getConnection), a downstream HTTP call without a timeout, lock contention, or deadlock.
• Check metrics: tomcat.threads.busy, pool active/pending, and request latency percentiles.
• Remedies: timeouts everywhere, bulkheads, bound pools, and fail fast.

The connection pool is exhausted: all connections are borrowed and requests wait up to connectionTimeout (default 30s) before throwing SQLTransientConnectionException. Look for leaked connections, long transactions, or work holding a connection while calling slow external services.

• Enable leakDetectionThreshold to log borrowers.
• Keep transactions short; avoid remote calls inside them; Open-Session-in-View holds connections for the whole request, so consider spring.jpa.open-in-view=false.
• Pool sizing is small (roughly cores x 2 + spindles); more is rarely better.

The retry executes the operation again, creating duplicates (double charge, duplicate order). Make it idempotent with an Idempotency-Key header: store key and result, return the stored response on replays.

@PostMapping("/payments")
ResponseEntity<Payment> pay(@RequestHeader("Idempotency-Key") String key, @RequestBody PayReq r) {
    return ResponseEntity.ok(service.payOnce(key, r)); // unique constraint on key
}

• Enforce with a unique DB constraint on the key, not a check-then-insert.
• Reject the same key with a different payload (422/409).

The upload was buffered in memory (e.g. @RequestBody byte[], file.getBytes(), or an in-memory multipart parser). Stream it to disk or storage instead and enforce limits.

@PutMapping("/blobs/{id}")
ResponseEntity<Void> put(@PathVariable String id, HttpServletRequest req) throws IOException {
    try (InputStream in = req.getInputStream()) {
        Files.copy(in, Path.of("/data", id), StandardCopyOption.REPLACE_EXISTING);
    }
    return ResponseEntity.noContent().build();
}

• Set max-file-size, max-request-size, and a proxy limit (client_max_body_size).
• Better: direct-to-object-store uploads via pre-signed URLs, or resumable/chunked uploads.

Limit body size at the proxy and container (server.tomcat.max-swallow-size, max-http-form-post-size, gateway limits), stream-parse where possible, and apply Jackson StreamReadConstraints (max nesting depth, string length, number length).

• Jackson 2.15+ enforces default limits (nesting 1000, string 20 MB; later raised/configurable).
• Validate early with Bean Validation and reject unknown fields if appropriate.
• Add timeouts for slow body delivery (slowloris).

Postman ignores CORS; browsers enforce it. The server response lacks Access-Control-Allow-Origin for the page's origin, or the preflight failed.

@Bean
CorsConfigurationSource cors() {
    CorsConfiguration c = new CorsConfiguration();
    c.setAllowedOrigins(List.of("https://app.example.com"));
    c.setAllowedMethods(List.of("GET", "POST", "PUT", "DELETE"));
    c.setAllowedHeaders(List.of("Authorization", "Content-Type"));
    UrlBasedCorsConfigurationSource s = new UrlBasedCorsConfigurationSource();
    s.registerCorsConfiguration("/**", c);
    return s;
}

• With Spring Security, enable http.cors(Customizer.withDefaults()) so the CORS filter runs before security rejects the unauthenticated preflight.

Credentialed requests need Access-Control-Allow-Credentials: true, a specific (non-wildcard) Allow-Origin, and the client must set credentials: 'include'. Wildcards for headers and methods are also not honoured in credentialed mode.

• SameSite=None; Secure is needed on the cookie for cross-site contexts.
• Add Vary: Origin when the allowed origin is echoed dynamically.

An attacker page auto-submits a hidden form to your endpoint; the browser attaches the session cookie, so the action executes. Add CSRF tokens (Spring Security default), set SameSite=Lax/Strict, and verify Origin.

http.csrf(c -> c.csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()));

• For SPAs with cookie auth, the SPA reads the XSRF-TOKEN cookie and echoes it in X-XSRF-TOKEN.
• JSON Content-Type requirement alone is not a defense in all cases.

This is stored XSS. Encode output for the HTML context, using the template engine's escaping, and avoid raw output.

<!-- Thymeleaf: escaped -->
<p th:text="${comment.body}"></p>
<!-- Dangerous: unescaped -->
<p th:utext="${comment.body}"></p>

• If rich text is required, sanitize with an allowlist library (OWASP Java HTML Sanitizer).
• Add a CSP and HttpOnly cookies as backup.

Broken object-level authorization (IDOR). The endpoint authenticates but does not verify ownership. Check that the resource belongs to the caller on every access.

@PreAuthorize("@orderAccess.canView(#id, authentication)")
@GetMapping("/orders/{id}")
Order get(@PathVariable long id) { return service.find(id); }

• Alternative: scope queries by owner (findByIdAndUserId) and return 404 to avoid revealing existence.
• Random IDs help but are not a substitute.

401 Unauthorized with WWW-Authenticate: Bearer error="invalid_token". The client reacts to 401 by refreshing the token or re-authenticating, whereas 403 signals that nothing will help.

• Spring Security's BearerTokenAuthenticationEntryPoint sets this correctly for resource servers.
• 403 is for authenticated users lacking permission.

If the server verifies the signature, the edit invalidates it and the token is rejected. It is accepted only if verification is missing, the secret is weak or leaked, or alg: none/algorithm confusion is allowed.

• Algorithm confusion: an RS256 public key used as an HS256 secret by a naive library. Pin the expected algorithm and key.
• Never trust decoded claims without verifying the signature (decoding is not validating).

localStorage is simple but readable by any XSS. An HttpOnly; Secure; SameSite cookie is not script-readable but needs CSRF defense. In-memory storage with a refresh via an HttpOnly cookie is a common compromise. The backend-for-frontend (BFF) pattern keeps tokens server-side entirely.

• BFF: browser holds only a session cookie; the BFF calls APIs with tokens.
• Short access-token lifetime limits damage in any model.

Authorization code flow with PKCE using the system browser. The app cannot keep a client secret, so PKCE binds the code exchange to a one-time verifier.

• Flow: generate code_verifier, send code_challenge (S256), later send code_verifier with the code.
• Use claimed HTTPS redirect URIs or app links, not embedded web views.

Client credentials grant: the service authenticates to the authorization server with its ID and secret (or mTLS/private key JWT) and obtains an access token scoped to its permissions.

spring:
  security:
    oauth2:
      client:
        registration:
          billing:
            provider: idp
            authorization-grant-type: client_credentials
            client-id: billing-svc
            client-secret: ${BILLING_SECRET}
            scope: invoices.read

• Cache tokens until near expiry; do not fetch per call.
• When propagating end-user identity, use token exchange rather than client credentials.

Return Cache-Control and an ETag. Browsers and CDNs serve repeats locally or revalidate with If-None-Match, receiving a cheap 304.

return ResponseEntity.ok()
    .cacheControl(CacheControl.maxAge(Duration.ofMinutes(5)).cachePublic())
    .eTag(String.valueOf(product.version()))
    .body(product);

• Spring also offers ShallowEtagHeaderFilter, which hashes the body: saves bandwidth but still runs the handler.
• Never cache personalized responses as public.

The response was cacheable by a shared cache (public, or no Cache-Control with heuristics), and the cache key ignored the identity (cookie or Authorization). Mark personalized responses Cache-Control: private or no-store, and set proper Vary.

• Shared caches generally do not store responses to requests with Authorization unless allowed with public/s-maxage.
• Cache-key mistakes also enable cache poisoning via unkeyed headers.

Use optimistic concurrency with ETags: the client sends If-Match: "<version>" on PUT; the server compares to the current version and returns 412 Precondition Failed (or 428 if the header is required but missing).

@PutMapping("/docs/{id}")
ResponseEntity<Doc> update(@PathVariable long id,
                           @RequestHeader("If-Match") String etag, @RequestBody Doc d) {
    return ResponseEntity.ok(service.update(id, etag, d)); // throws on version mismatch
}

• Back it with a JPA @Version column.

The client probably did not send Accept: application/xml, or no XML converter is on the classpath. Add jackson-dataformat-xml and let Spring negotiate on Accept.

• Default order uses the first converter that supports the requested type; */* gets the default (JSON).
• Query-parameter-based negotiation (?format=xml) is disabled by default in Spring 6 and must be configured.

The Content-Type of the request is missing or not handled by the endpoint (consumes) or by any HttpMessageConverter. Check that the client sends Content-Type: application/json and that the mapping accepts it.

• Posting a form (application/x-www-form-urlencoded) to a @RequestBody JSON endpoint gives 415.
• Charset or typo errors (application/jsonn) cause it too.

getInputStream() can be consumed only once. Wrap the request in a caching wrapper so it can be read again.

ContentCachingRequestWrapper w = new ContentCachingRequestWrapper(req);
chain.doFilter(w, res);
byte[] body = w.getContentAsByteArray(); // available after the controller read it

• ContentCachingRequestWrapper caches only what downstream actually reads; reading it up front requires a custom wrapper.
• Log selectively and mask secrets; cap the logged size.

The response was already committed (headers flushed) when the servlet wrote and flushed the body or filled the buffer. After that headers and status can no longer change.

• Check response.isCommitted().
• Set headers before chain.doFilter, or wrap the response (HttpServletResponseWrapper) and buffer the output.
• Spring's OncePerRequestFilter plus ContentCachingResponseWrapper lets you inspect the body, then call copyBodyToResponse().

Filters mapped to multiple dispatcher types (REQUEST, FORWARD, ERROR, ASYNC) run for each dispatch. Extend OncePerRequestFilter, which tracks execution via a request attribute, and override shouldNotFilterAsyncDispatch/shouldNotFilterErrorDispatch as needed.

• In Spring Boot, FilterRegistrationBean.setDispatcherTypes controls this.
• Async requests are dispatched twice by design (initial and result dispatch).

Concurrent threads read-modify-write the shared field, losing updates. Use AtomicInteger or LongAdder, or avoid shared state.

public class CounterServlet extends HttpServlet {
    private final AtomicInteger hits = new AtomicInteger();
    protected void doGet(HttpServletRequest rq, HttpServletResponse rs) throws IOException {
        rs.getWriter().println(hits.incrementAndGet());
    }
}

• A plain int with hits++ is not atomic; synchronized on doGet would serialize all requests.
• A per-node counter is wrong across a cluster; use a shared store.

Use Post/Redirect/Get: after processing the POST, respond with a 303 redirect to a confirmation GET page, so refresh repeats the harmless GET. For double-click and retries, add an idempotency or one-time form token.

@PostMapping("/orders")
String create(OrderForm f, RedirectAttributes ra) {
    long id = service.create(f);
    ra.addFlashAttribute("msg", "Created");
    return "redirect:/orders/" + id;
}

Use getSession(false) where a session is not needed, avoid creating sessions on public pages (JSPs create one by default unless <%@ page session="false" %>), shorten the timeout, and consider stateless endpoints.

• Spring Security's SessionCreationPolicy.STATELESS stops creating sessions for APIs.
• Rate-limit or filter bots; monitor active session counts.

Configure the app to honour X-Forwarded-For/-Proto/-Host (or Forwarded) from trusted proxies.

server:
  forward-headers-strategy: native   # or framework
  tomcat:
    remoteip:
      internal-proxies: "10\\.\\d+\\.\\d+\\.\\d+"

• native uses the container's RemoteIpValve; framework uses Spring's ForwardedHeaderFilter.
• Trust the headers only from your own proxies.

sendRedirect("/x") is relative to the server root, not the application's context path, while sendRedirect("x") is relative to the current URL. Prefix request.getContextPath(), and behind a proxy ensure forwarded headers are processed.

• Spring's redirect: prefix prepends the context path for /-leading URLs.
• Redirects build absolute Location from the Host the container sees.

Make it asynchronous: return 202 Accepted with a Location to a status resource, process on a worker queue, and let the client poll or receive a webhook/SSE. If the client must wait, use DeferredResult/Callable.

@PostMapping("/reports")
ResponseEntity<Void> start(@RequestBody ReportReq r) {
    String id = jobs.submit(r);
    return ResponseEntity.accepted().location(URI.create("/reports/" + id)).build();
}

• Jobs belong in a durable queue so they survive restarts.
• Proxy idle timeouts (often 60s) will cut long synchronous calls anyway.

Typical causes: complete() never called (timeout fires), asyncSupported missing on a filter or servlet, response written after completion, or the work thread threw before writing.

• Register an AsyncListener with onTimeout and onError.
• Set an explicit timeout (setTimeout); the default is container-specific (Tomcat 30s).
• Ensure exceptions in the worker path always end with complete() or dispatch().

The proxy buffers upstream responses. Disable buffering for that route (proxy_buffering off; or the X-Accel-Buffering: no response header), disable compression for the stream, and keep idle timeouts above your heartbeat interval.

• Send periodic comment lines (:\n\n) as keepalives.
• SseEmitter timeout in Spring defaults to the async timeout; set it deliberately.

Default to Tomcat: best supported in Spring Boot, widest operational knowledge and tooling. Choose Undertow or Jetty for specific needs such as lower memory, particular WebSocket behavior, or existing expertise, and decide with a load test of your workload.

• The server rarely dominates latency; the database and downstream calls do.
• Check Jakarta EE/Servlet version compatibility with your Spring Boot version before switching.

Idle connections are cheap on non-blocking servers (Netty/WebFlux, Undertow, Jetty async) but would exhaust a thread-per-request pool if each holds a worker. With Tomcat NIO, idle WebSockets do not pin worker threads, but blocking handlers do; virtual threads also fit.

• Size file descriptors (ulimit -n) and max-connections.
• Plan memory per connection and heartbeat/idle-timeout policy.
• Scale out with sticky routing or a broker (Redis, Kafka) for fan-out.

JDBC blocks the Netty event-loop thread. With only a few loops, a handful of slow queries stall all requests. Use R2DBC, or offload blocking calls to a bounded elastic scheduler.

Mono<User> find(long id) {
    return Mono.fromCallable(() -> jdbcRepo.findById(id))
               .subscribeOn(Schedulers.boundedElastic());
}

• BlockHound detects blocking calls in tests.
• If most of your stack is blocking, Spring MVC (with virtual threads) is a better fit.

Introduce /v2 (or a new media type) next to /v1, keep both running, announce deprecation with Deprecation and Sunset headers plus docs, track per-client usage of v1, and remove it only after the sunset date and usage drop.

• Share business logic and diverge only in the web layer/DTO mapping.
• Contract tests protect v1 behaviour.
• Avoid forking databases per version.

Switch from offset to keyset pagination with a deterministic, indexed sort and a unique tiebreaker. Return an opaque cursor; both the cost and the duplicates/gaps problem disappear.

List<Order> next(Instant ts, long id, int size) {
    return repo.findNext(ts, id, PageRequest.ofSize(size)); // WHERE (created_at, id) < (?, ?)
}

• Add a composite index (created_at DESC, id DESC).
• Keep offset only for small, bounded datasets or when random page access is required.

Per-client rate limiting with a token bucket in the gateway or a shared Redis store, returning 429 with Retry-After. Combine with request timeouts, bulkheads and concurrency limits so one tenant cannot consume all threads.

Bucket bucket = Bucket.builder()
    .addLimit(Bandwidth.simple(100, Duration.ofMinutes(1)))
    .build();
if (!bucket.tryConsume(1)) { response.setStatus(429); return; }

• Key by API key or authenticated principal, not only IP (NAT sharing).
• Tier limits by plan; log and alert on sustained throttling.

Make the spec part of CI: generate it from code (springdoc) and diff against the committed spec to catch breaking changes (openapi-diff), or go design-first and generate server interfaces so code cannot drift. Add contract tests (Spring Cloud Contract, Pact, schema validation).

• Annotate error responses and security schemes, not just success cases.
• Fail the build on unreviewed contract changes.

Validate with Bean Validation (@Valid) and map MethodArgumentNotValidException to a 400 ProblemDetail in a central @RestControllerAdvice.

@RestControllerAdvice
class Errors {
    @ExceptionHandler(MethodArgumentNotValidException.class)
    ProblemDetail invalid(MethodArgumentNotValidException e) {
        ProblemDetail p = ProblemDetail.forStatus(400);
        p.setProperty("errors", e.getFieldErrors().stream()
            .collect(Collectors.toMap(FieldError::getField, FieldError::getDefaultMessage, (a, b) -> a)));
        return p;
    }
}

• Set server.error.include-stacktrace=never.

A keep-alive timeout mismatch: the backend closes an idle connection just as the proxy reuses it. The proxy's upstream idle timeout must be shorter than the server's keep-alive timeout.

• Tomcat keepAliveTimeout defaults to the connection timeout (20s in Boot); load balancers (e.g. AWS ALB 60s) idle timeouts should sit below backend timeouts.
• Enable retries for idempotent requests only.

Enable response compression (gzip or Brotli), paginate, support field selection, and cache with validators.

server:
  compression:
    enabled: true
    mime-types: application/json,text/html
    min-response-size: 2048

• Do not compress already compressed content (images, zip).
• Compression costs CPU and can interact with TLS attacks (BREACH) when secrets are reflected in responses.

Method override lets HTML forms (GET/POST only) simulate PUT/DELETE; Spring's HiddenHttpMethodFilter honours _method on POST. It is a risk if CSRF/authorization rules are applied by the original method, or if caches and proxies treat the POST differently than the logic does.

• Apply authorization after override resolution (the filter runs early in the chain).
• Disable the filter in pure API services (it is off by default in Boot 2.2+).

GET is assumed safe: browsers prefetch, crawlers follow links, proxies cache and retry it. Side effects will fire unexpectedly and duplicates can occur. Move state changes to POST/PUT/DELETE.

• Sensitive parameters in GET URLs leak into logs, history and Referer headers.
• Analytics-only writes are acceptable if truly harmless, but make them asynchronous.

Yes. Idempotency concerns server state: after one or many DELETEs the resource is gone. The response code may differ between calls.

• Returning 204 on a repeat is also valid and friendlier to retrying clients.
• Soft deletes remain idempotent if the flag is simply set.

Handle expiry explicitly: configure an invalid-session strategy that redirects with a message, return 401 JSON for AJAX calls (via an AuthenticationEntryPoint), and use a session timeout with client-side warnings or silent refresh for long forms.

http.sessionManagement(s -> s.invalidSessionUrl("/login?expired"));

• Remember-me tokens can restore authentication, with persistent token storage.
• Pending form data is lost; save drafts client-side if needed.

CSRF protection is on by default and the requests lack the token. Include it (form hidden field, X-CSRF-TOKEN or X-XSRF-TOKEN header), or disable CSRF only for stateless token-authenticated APIs.

http.csrf(csrf -> csrf.disable()); // only for stateless bearer-token APIs

• Thymeleaf forms add the token automatically with th:action.
• GET requests succeed since they are not protected.

Never build file paths from raw input. Look up files by ID in a database or resolve against a base directory and verify the normalized path stays inside it.

Path base = Path.of("/data/files").toRealPath();
Path p = base.resolve(name).normalize();
if (!p.startsWith(base)) throw new ResponseStatusException(HttpStatus.BAD_REQUEST);

• Send Content-Disposition: attachment; filename*=UTF-8''... and a safe Content-Type.
• Authorize per file and stream using Resource/StreamingResponseBody; support Range for resumption.

Raise the multipart limits, the defaults being 1 MB per file and 10 MB per request, and also any proxy limit.

spring:
  servlet:
    multipart:
      max-file-size: 20MB
      max-request-size: 25MB

• Nginx: client_max_body_size; Tomcat has maxPostSize for form posts (not multipart parts).
• Handle MaxUploadSizeExceededException with a 413 ProblemDetail.

Use an OIDC authorization server. The SPA uses authorization code + PKCE (or a BFF); partners use client credentials. The API is an OAuth2 resource server validating JWTs (signature, iss, aud, exp) and enforcing scopes plus object-level checks.

• Short access tokens (5-15 min), rotated refresh tokens, JWKS-based key rotation.
• Gateway: TLS, rate limiting per client, request size limits, CORS allowlist.
• Observability: audit logs with subject and client ID, never tokens.