Security

The WAR of this page adds the pieces that a security discussion needs to the Bookshelf of the getting started page: pages that echo input in every HTML context, a review form that stores text and needs a token, an upload servlet, a protected area and a handful of configuration files.

The dependency that is new compared with the earlier pages is the encoder, a small library of the OWASP project:

Maven resolves the encoder core library (same version) through it. 1.5.0 is the latest release on Maven Central on 2026-10-08.

Source: Maven Central — org.owasp.encoder:encoder-jakarta-jsp 1.5.0

Source: OWASP Java Encoder project

A JSP page has more inputs than the request parameters it reads. The expression language reads all of them with the same syntax, which is what makes the habit necessary.

Three rules cover almost every defect on this page. Encode on output, for the context in which the value is written, as late as possible. Never turn text into code: no expression, no OGNL (on the Struts side), no script or SQL is built from input. Keep the application away from the places where the container serves files directly. The sections below apply the rules one context at a time.

Source: OWASP — XSS Prevention Cheat Sheet, Output Encoding

The expression language writes the value it computes to the response as it is. An expression in template text, ${param.q}, does not escape anything, and neither does an expression in a tag attribute whose handler prints the value unescaped. The search page of the Bookshelf (see the Getting Started page) shows the four ways of writing the same parameter that the page set offers:

Requested with q=<b>x</b>&"' (the parameter encoded for the URL), the page answered:

The first line is a cross-site scripting hole: the markup in the parameter became markup in the page, and a script element would have run. The other three are correct for HTML text and for a quoted HTML attribute. c:out and fn:escapeXml replace exactly the five characters <, >, &, " and ' (by <, >, &, " and '), which is the whole of their job: they are an HTML-body encoder, not a universal one. The OWASP encoder writes numeric references for the quotes (", '), which are the same characters. The details of c:out (the default attribute, escapeXml taking any text as false except "true", reader values) are on the JSTL core page and those of fn:escapeXml on the JSTL functions page; the one fact to take away is that the default of c:out is the safe one, and that only a literal escapeXml="false" on text the page’s own authors control may switch it off.

Which of the four to use is a style choice. c:out is the idiom that reviewers recognise and that a search for "an ${...} that is not inside a tag" finds. ${fn:escapeXml(x)} is convenient inside an attribute value that contains other text. The encoder tags and functions (the next section) are the only ones that also cover the other contexts, so a page that uses them for the other contexts may use them for HTML text as well, to have a single vocabulary.

Source: Jakarta Standard Tag Library 3.0 — 4.2 c:out

Source: Jakarta Standard Tag Library 3.0 — 15.5 fn:escapeXml

Source: OWASP — XSS Prevention Cheat Sheet, Output Encoding for HTML Contexts

The unescaped ${b.title} of the first Bookshelf page of this section (an expression in template text) is the same hole as ${param.q} as soon as a title comes from a form or an import: an expression is only as safe as the text it prints. The syntax and escaping page lists the places where an expression is printed, and the scripting elements page shows that <%= x %> is unescaped by definition.

HTML text is one context. The same value needs a different encoding when it lands in a quoted attribute, in a JavaScript string, in a URL or in CSS, and no single function is right for all of them. The diagram is the decision the page author makes for every dynamic value.

The OWASP Java Encoder implements the rules of the cheat sheet. For Jakarta Pages it ships as encoder-jakarta-jsp, whose tag library has the URI owasp.encoder.jakarta (a second, advanced library has the URI owasp.encoder.jakarta.advanced; the javax artifact is a separate encoder-jsp on Maven Central). The library offers each encoder both as a tag (<e:forHtml value="${x}"/>) and as an EL function (${e:forHtml(x)}); the 1.5.0 TLD declares the same fifteen names twice: forHtml, forHtmlContent, forHtmlAttribute, forHtmlUnquotedAttribute, forCssString, forCssUrl, forUri, forUriComponent, forJavaScript, forXml, forXmlContent, forXmlAttribute, forXml11, forCDATA and forJson.

Source: OWASP Java Encoder project

Source: OWASP — XSS Prevention Cheat Sheet, Output Encoding for HTML Attribute Contexts

Source: OWASP — XSS Prevention Cheat Sheet, Output Encoding for URL Contexts

A value that is stored and shown later is the same defect, with a longer path and a larger audience. The review page prints the book and the text of every review with c:out:

A review posted with the text <script>alert(1)</script> was listed as:

The encoding happens on output, in the page that knows the context, not on input in the servlet: a value escaped when it is saved is double-encoded the next time it passes through a c:out, and wrong for any other consumer of the same data, such as a JSON endpoint or a PDF. Input validation (a length limit, a character set, a format) is a separate defence that reduces what can be stored. A page that must show formatted user text (reviews with bold and links) cannot use an encoder, because it would show the tags; it needs an HTML sanitizer with an allow list of elements and attributes, run when the text is saved or displayed, and the Content-Security-Policy below as a second line.

Source: OWASP — XSS Prevention Cheat Sheet, HTML Sanitization

A policy that the browser enforces limits what an injected script can do and, with a nonce, forbids inline scripts that the server did not mark. The Bookshelf sets one for every response with a filter and passes the nonce to the pages through a request attribute:

Every script block of a page then carries the nonce, <script nonce="${cspNonce}">, and the response had:

The nonce is base 64 text from a secure random generator, so printing it without encoding is safe; it must be fresh for every response, because a nonce that repeats is a password that is published. The policy is a defence in depth, never a replacement for encoding.

Tomcat ships a filter for three more headers. Adding it to web.xml is two elements, and no code:

and a response of the Bookshelf then carried X-Frame-Options: DENY and X-Content-Type-Options: nosniff. The filter documentation names three protections: HSTS (added only to responses for HTTPS requests), click-jacking protection and content-type sniffing protection; the policy header above is not among them, which is why the application sets it itself. The filter is Tomcat-specific, so a WAR that must run on other containers sets the same headers in a filter of its own.

Source: OWASP — Content Security Policy Cheat Sheet, Defense Against XSS

Source: Apache Tomcat 11 — HTTP Header Security Filter

Encoding protects the output. The second family of defects is about input that becomes code. An expression is a small program: since EL 2.2 it can call methods, and with EL 3.0 the classes of java.lang are imported by default. When text from a request is handed to something that evaluates it as an expression, the attacker writes the program. A value that is only printed is never evaluated again: with q set to ${1+1}, the search page printed ${1+1} (the raw, c:out and fn:escapeXml lines above), because ${param.q} is evaluated once, and its result is a string, not source text.

The defect needs a component that takes a string and parses it. The Bookshelf contains one on purpose, a custom tag that a careless author wrote to "let templates carry expressions":

Used as <bs:eval expr="${param.q}"/>, the page evaluated the value of the parameter a second time ("double evaluation"). The requests and the responses of the run:

The last three rows show that an attacker reaches static methods and objects, not only the data of the request; the Runtime row ran an object method on a class the page never imported. Replacing availableProcessors() with a method that starts a process is the end of the story, which is why the OWASP page on expression language injection rates the impact as high. The same pattern exists in the wild in tag libraries that evaluate a message or a label: that page describes the spring:message tag of Spring versions before 3.0.6, which resolved expressions twice, and states that the pattern must be avoided. The defences:

The EL configuration and the evaluator API are on the EL configuration and ELProcessor page; the Spring tags and the Struts OGNL equivalent are on the Spring MVC with JSP and ValueStack, ActionContext & OGNL pages of this section, and on the Struts side the same defect has had a long list of severe CVEs.

Source: OWASP — Expression Language Injection

Source: Jakarta Expression Language 6.0 specification

A scriptlet is Java code in the page, in the thread of the request, with the full power of the web application. The first defence is to forbid it. One property group in web.xml turns every <% %>, <%! %> and <%= %> of the web application into a translation error:

A page legacy.jsp that contained <% out.println("scriptlet"); %> failed on the first request with a 500 response (the error valve of the Bookshelf prints no report, see below) and the log said:

The error is a feature: a pull request that adds a scriptlet fails in the first test that renders the page. The property groups, their url-pattern rules and the stricter ScriptFreeTLV validator are described on the configuration page and the scripting elements page, which also shows how to migrate a page away from scriptlets.

Scriptlets are also where the classic server-side vulnerabilities of old JSP books live. The catalogue of "common JSP tasks" of a book of 2001 includes a page that runs Runtime.exec with parts of the request, a mail form that puts form values into message headers, and a "view source" button that reads a file whose name comes from the request: each is an injection of a different kind (command, header, path traversal). The rule is the same for all: a value from outside is never part of a command line, a header or a path; it is a parameter to an API that takes it as data (ProcessBuilder with a fixed program and an argument list, a mail library that rejects line breaks, a lookup by identifier).

Source: Jakarta Pages 4.0 — Disabling Scripting Elements

Source: OWASP — OS Command Injection Defense Cheat Sheet

A JSP in the public part of the web application is a URL. Anyone can request it, with any parameter, without the servlet that was meant to prepare its model; it can show half-built pages, stack traces or data from an attribute that is not set. Files under WEB-INF are never served by the container, and a servlet reaches them with a RequestDispatcher. The Bookshelf has one JSP of each kind, and the run asked for both and for the neighbours:

The Struts security guide has a section titled "Never expose JSP files directly": a Struts result that points to a JSP in the public tree lets a visitor skip the action. In a plain JSP application the servlet plays the action’s role, and the same discipline applies. Two corollaries. A JSP that must be reachable directly (a static-looking page that only uses the taglib) is still safer under a servlet mapping or a jsp-file servlet declaration than in the public tree. And the container’s view source and directory index features of the early books (a "view source" button, a directory listing page) are not needed by an application: the Default Servlet’s listings parameter is false by default, so leave it, and do not write a page that lists a folder.

Source: Apache Struts — Security Guide, Never expose JSP files directly

Source: Jakarta Servlet 6.1 — 10.5 Directory Structure

A JSP takes part in the session by default (session="true" is the default of the page directive), so an anonymous visitor who only reads the search page receives a session cookie. The response header of the Bookshelf’s search page had:

This is a performance and a privacy concern, not a flaw by itself, but it matters for security in two ways: a session id is issued before the user logs in (so the id must change at login, below), and a page that does not need a session should say so with <%@ page session="false" %>. The implicit objects page has the rules.

Source: Jakarta Pages 4.0 — JSP Configuration

Four lines of web.xml and one Context attribute harden the session cookie. The first three are the servlet specification’s cookie-config; the last is Tomcat’s:

With both in the WAR the cookie of the response above has Secure; HttpOnly; SameSite=Strict. HttpOnly hides it from scripts, so an XSS cannot read the id (it can still act as the user, which is why XSS must not be allowed in the first place); Secure keeps it off plain HTTP; SameSite=Strict keeps it off cross-site requests; and the COOKIE tracking mode prevents the ;jsessionid= suffix on URLs. The Bookshelf scratch application runs on plain HTTP; curl still returned the Secure cookie from its jar for localhost, but a browser on a non-TLS host that is not local does not send it back. SameSite=Strict also means that a link from another site arrives without the cookie, so a user who follows an e-mail link to a logged-in page sees the login page once; Lax allows the cookie on top-level navigations and is the usual compromise. The servlet fundamentals page lists the cookie attributes that the specification itself defines, among them the generic attribute element of cookie-config (the specification’s way of setting SameSite), and the Tomcat-specific CookieProcessor is the alternative that also covers the cookies the application creates itself.

Session fixation is the attack where an attacker obtains a session id and gets the victim to use it, so that the victim’s login authenticates the attacker’s session. The defence is to change the id at the moment of login:

curl -X POST with the session cookie answered changed: true and the cookie in the jar had a new value. The attributes of the session (the cart, the token) survive the change; only the id differs. Tomcat’s authenticators change the id when a user logs in (the changeSessionIdOnAuthentication option of the authenticator valves, documented with the Tomcat valves); an application that authenticates in its own servlet must call changeSessionId itself.

Source: Jakarta Servlet 6.1 — Session Integrity

Source: Apache Tomcat 11 — Cookie Processor, Standard Implementation

Source: OWASP — Session Management Cheat Sheet, Cookies

The session security section of the servlet page has the full checklist, including the idle timeout and URL rewriting.

The servlet specification can require a secure transport for a set of URLs. A user-data-constraint with the guarantee CONFIDENTIAL makes the container redirect a plain HTTP request to the connector’s redirectPort:

Which is what the run showed (the redirect port of the scratch server is 18443). A site that is TLS-only as a whole configures the constraint for /*, or terminates TLS in a reverse proxy and tells Tomcat about it with the proxy’s headers; the servlet container then must trust the proxy’s forwarded headers only from the proxy’s address.

Source: Jakarta Servlet 6.1 — Specifying Security Constraints

A browser attaches the cookie of a site to every request to that site, including a request that a page of another site triggers. A form on a hostile page that posts to the Bookshelf’s review URL would be authenticated as the visitor. The defences, in the order a servlet application should adopt them:

The run: a POST without a session answered 403, a POST with a session but without the field answered 403, and a POST with the token found in the rendered form answered 302 to /g7security/reviews and added the review. The redirect after the post is the post/redirect/get pattern, which also prevents a duplicate on reload. The token is 43 characters of URL-safe base 64 for 32 random bytes; MessageDigest.isEqual compares in time that does not depend on how many leading characters match. A JSP page that renders a form must write the token (a tag file that every form uses is the way to not forget it), and a page that is served from a cache must not contain a token. Tomcat also ships a CsrfPreventionFilter that adds tokens to URLs and checks them, and Spring Security and Struts have their own mechanisms; the principle is the same.

Source: OWASP — CSRF Prevention Cheat Sheet, Synchronizer Token Pattern

Source: OWASP — CSRF Prevention Cheat Sheet, SameSite Cookie Attribute

Source: Apache Tomcat 11 — CSRF Prevention Filter

A cover upload is a way for a stranger to put a file on the server, and the CVE list below is mostly the story of what happens when that file ends up where the container can execute or overwrite it. Four rules:

The run, with curl -F: a PNG file answered stored ca1be081-....png outside the web root; a file with the content type application/x-jsp answered 415; a 2 MB file with the type image/png answered 413 (over the 1 MB limit). The content type is a claim of the client, so a production application also checks the file signature (the first bytes) and, for images, decodes and re-encodes the image, which destroys most polyglot files. The file-upload cheat sheet has the full list, and the multipart API is on the Servlet fundamentals page.

Source: Jakarta Servlet 6.1 — MultipartConfig

Source: OWASP — File Upload Cheat Sheet, File Storage Location

Source: OWASP — File Upload Cheat Sheet, Upload and Download Limits

Static files, welcome files and (with listings) directory pages are served by the Default Servlet that Tomcat registers for every web application in its global conf/web.xml. Its readonly initialisation parameter is true by default, and the security guide says what changing it means: clients can delete or modify static resources and upload new ones, so it should not be changed without requiring authentication. The two behaviours, side by side on the Bookshelf:

and the same request against a second copy of the WAR whose web.xml overrides the servlet named default with readonly set to false:

With the parameter set to false anyone can create files in the web application; the .jsp request was refused here because the container maps *.jsp to the JSP servlet, but the history of the next table shows that the protection is thin: a write-enabled Default Servlet is the root of CVE-2017-12617 (a JSP uploaded with PUT is executed), of CVE-2024-50379 and CVE-2024-56337 (a race on case-insensitive file systems that treats an uploaded file as a JSP) and a prerequisite of CVE-2025-24813 (a partial PUT). The rule is short: leave readonly alone, and do not use PUT and DELETE for uploads at all, use a servlet with the rules of the previous section. Both scratch copies of the WAR were removed after the test.

Source: Apache Tomcat 11 — Security Considerations, web.xml

Source: Apache Tomcat 11 — Default Servlet

The Tomcat security considerations page is the checklist of the container; it says that Tomcat is reasonably secure for most use cases by default and that some environments need more. The items that matter for a JSP deployment are below; the ones marked "observed" were run on the Bookshelf, the others were checked against the documentation of Tomcat 11.

The valve of the Bookshelf is declared in META-INF/context.xml, which affects only this web application (a server-wide valve goes into server.xml or conf/context.xml; a hosted environment that does not trust its tenants sets the host’s deployXML to false so that a packaged context.xml is ignored):

A request for a missing page then had a body that carried only the status heading:

whereas an application without the valve (another WAR of the same server) printed, besides the heading, a "Type" and a "Message" with the requested path, a "Description", and the footer Apache Tomcat/11.0.26. The Tomcat documentation says that disabling both attributes leaves only the HTTP status code. The following server.xml fragments are shown from the documentation and were not applied to the shared test server:

The secret in the snippet is a placeholder, as everywhere in this section: a real one comes from the environment or a secrets store, never from a file in the repository.

Source: Apache Tomcat 11 — Security Considerations, Default web applications

Source: Apache Tomcat 11 — Security Considerations, Server

Source: Apache Tomcat 11 — Security Considerations, Connectors

Source: Apache Tomcat 11 — Security Considerations, Valves

Source: Apache Tomcat 11 — Error Report Valve

Source: Apache Tomcat 11 — AJP Connector

An application that authenticates in its own servlet, with a table of users and a hand-made "logged in" flag in the session, as the books of the early 2000s did, owns every defect that comes with it: unhashed passwords, a missing session change, no lock-out and a check that some page forgets. The platform’s alternatives are, in the order of preference for a new application, Jakarta Security or Spring Security (see the Spring Security page), or at least the container’s declarative security: a security-constraint names URLs and roles, a login-config the mechanism, and the realm of the server holds the users.

An anonymous request for /admin/index.html answered 401 with WWW-Authenticate: Basic realm="Bookshelf", charset=UTF-8. The run did not log in: the shared server has no user for the role and the page never contains a password. The facts to know are those of the Tomcat guide. BASIC and FORM send the user name and the password in clear text, so they are for HTTPS only (combine the constraint with CONFIDENTIAL). The realms do not lock accounts by default, and the MemoryRealm and the UserDatabaseRealm are not for large or changing installations. FORM login is a page of the application that posts to j_security_check. A hashed password store, a per-user salt, and a real identity provider are the production answer. Hand-made login code in a filter (HttpSession attribute user) is still seen; where it exists it must at least call changeSessionId at login, throw the session away at logout and compare secrets in constant time.

The HttpServletRequest methods isUserInRole, getUserPrincipal and getRemoteUser read the container’s identity, so a page can hide a link with ${pageContext.request.isUserInRole('bookshelf-admin')} (hiding a link is cosmetic, the constraint is the enforcement).

Source: Jakarta Servlet 6.1 — Form Based Authentication

Source: Apache Tomcat 11 — Security Considerations, Realms

The vulnerabilities below were checked on 2026-10-08 on the Tomcat 9, 10 and 11 security pages and on the CVE Program records; the Struts rows were checked against the Struts security bulletins. A CVE id is shown only after that check. "Fixed in" lists the first release of each line that contains the fix; every release of the Tomcat 11.0 line after 11.0.3 contains all of them, and the application of this page runs on 11.0.26.

The bulletins S2-045, S2-066 and S2-067 are at the Apache Struts wiki. The later Struts bulletins (S2-068 and the 2026 ones, among them an OGNL injection in the legacy RESTful action mapper) and their fixed-in versions are on the Struts security bulletins page of this section.

Two lessons repeat in the table. First, five of the six Tomcat entries need the Default Servlet to be writable or AJP to be reachable: configuration the application of this page does not have. Second, the one entry about JSP output (CVE-2024-52318) was a regression in the container, fixed within weeks, which is what makes a current patch release part of the defence. The classic custom tags page has the technical side in the pooling section.

Source: Apache Tomcat 11 — Security Reports, Fixed in 11.0.1

Source: Apache Tomcat 11 — Security Reports, Fixed in 11.0.2

Source: Apache Tomcat 11 — Security Reports, Fixed in 11.0.3

Source: Apache Tomcat 10 — Security Reports, Fixed in 10.1.34

Source: Apache Tomcat 10 — Security Reports, Fixed in 10.1.35

Source: Apache Tomcat 9 — Security Reports, Fixed in 9.0.31

Source: Apache Tomcat 9 — Security Reports, Fixed in 9.0.98

Source: Apache Tomcat 9 — Security Reports, Fixed in 9.0.99

Source: Apache Struts — Bulletin S2-045

Source: Apache Struts — Bulletin S2-066

Source: Apache Struts — Bulletin S2-067

The output encoders above protect the browser. Two more places take request text and hand it to something that gives it meaning: the database and the Location header. The Bookshelf search of this page reads q from the request and the catalogue page of the MVC with Servlets & JSP page passes it to a repository. If the repository builds the SQL by concatenation, a q of zzz%' OR title LIKE '% closes the string and adds a condition that is always true. With a bound parameter the same text is only a string to look for. The listing is the pair of methods that a scratch run exercised against an in-memory H2 database with two books (Dune and Emma).

Source: OWASP — SQL Injection Prevention Cheat Sheet, Prepared Statements

The output of the run, for the hostile q and for the harmless Du:

The concatenated query returned every book, including the ones that the search should not have matched; the bound query returned none. A value can be bound, but a column name or a sort direction cannot, which is why the BookService of the MVC page maps the sort parameter through a fixed map and never pastes it into the SQL. The sql:query tags of the JSTL SQL and XML page bind with sql:param, but a query in a view is the wrong place for any of this.

The second sink is the redirect. A login or a form that takes a next parameter and calls sendRedirect with it sends the browser wherever the link says, which turns the application into a trusted launching pad for a phishing page. safeTarget accepts only a path that starts with a single slash, and the same run printed:

Source: OWASP — Unvalidated Redirects and Forwards Cheat Sheet

Source: OWASP — Java Security Cheat Sheet, Injection Prevention in Java

The rules do not depend on the view technology. The template security and XSS page of the Thymeleaf section shows the same contexts with th:text and th:utext; the Django security page and the ASP.NET Core security hardening page have the framework’s own defaults, and the Spring Security page has the authentication and CSRF machinery for a Spring Boot application. For the browser side, the CORS page explains the cross-origin rules that interact with the cookie and token decisions above. The Struts counterpart of this page, the Struts security hardening page, covers the framework side.

Source: Apache Tomcat 11 — Security Reports

Source: Apache Tomcat 9 — Security Reports

The section bibliography lists Web Development with JavaServer Pages (Manning, 2001), whose chapters on filters and listeners, deployment and common tasks, and the example catalogue ("JSP by example"), and Struts in Action (Manning, 2002), whose last sample application uses container-managed security. Their concepts remain: declarative security, filters for authentication, the question of where a file lives. The advice around them does not hold.

Source: Manning — Web Development with JavaServer Pages, Second Edition

Source: Manning — Struts in Action