How does Java Server Pages work?

How JSP turns source pages into server-executed output

A JSP is not served as raw page text. The container first translates the JSP into a Java servlet, compiles it, and then executes that server-side code to build the final response. That means markup, expression output, tags, and Java-backed logic are processed before the browser ever sees HTML. The security consequence is that control over the JSP source can become control over runtime behaviour.

The compile-and-execute model is what makes JSP useful for dynamic pages, but it also means the page is part template and part executable artefact. Changes to the JSP can alter content generation, access checks, or server calls, so it should be treated more like application code than a static document. That is why review of deployment paths, file permissions, and update workflows matters as much as the page content itself.

Because the response is generated on the server, JSPs often sit close to authentication, business logic, and backend data access. A harmless-looking page can therefore depend on privileged server context, shared libraries, and request parameters. If those inputs are not constrained, the page may expose internal state or perform actions the author did not intend.

Where JSPs become security-sensitive in practice

Security teams should pay close attention to the places where JSPs accept input, call helper classes, or expose administrative actions. Those are the points where server-side rendering can turn into code execution, command execution, or injection if the page is writable, uploadable, or reachable through an unsafe include path. The highest-risk JSPs are rarely the flashy ones; they are the utility pages with powerful backend reach.

Unauthorised edits are especially dangerous because a JSP can function as a web shell once it is placed in a runnable location. That risk is amplified when upload handling, file renaming, archive extraction, or CI/CD deployment paths allow attacker-controlled content into the web root. Review whether the application can execute files from directories that also accept user uploads, backups, or temporary artefacts.

JSPs also deserve inspection for injection points in expressions, scriptlets, includes, and any code that passes request values into downstream commands, SQL queries, or reflection-based calls. Modern JSP development avoids many older patterns, but legacy pages still exist in enterprise estates and are often the most dangerous because they are least reviewed.

Operational view: build, deploy, and review JSPs as executable assets

At deployment time, the question is not only whether the page works, but whether the container can compile it from a trusted source and whether the runtime can execute only what was approved. A JSP that is versioned, code-reviewed, and deployed through controlled pipelines is far easier to govern than one edited directly on the host. The same control expectations should apply to hotfixes, emergency uploads, and staging-to-production promotion.

It also helps to distinguish harmless presentation logic from privileged server actions. JSPs that only render view data are lower risk than pages that trigger administrative functions, mutate records, or expose diagnostics. If a JSP does more than present output, the surrounding access control, logging, and change management need to be proportionately stronger.

For broader server-side web hardening, the same review mindset used for API exposure and web application controls applies here. Inputs, execution paths, and administrative endpoints should be narrow, observable, and testable. A JSP is safe only when the surrounding server configuration prevents it from becoming an arbitrary execution surface.

Risk and Threat Considerations

JSP risk is concentrated in execution, not appearance. A page that can be written, uploaded, or indirectly altered may become a persistence point, a privilege escalation path, or a simple web shell, especially when the application server runs with broad filesystem or application privileges.

Failure mechanism: Attackers abuse writable JSP locations, unsafe includes, or injection into server-side logic to execute code in the application context or plant a persistent backdoor.

Impact: The result can be remote command execution, data access, account takeover, lateral movement, or continued control of the web tier until the file or the server is rebuilt.

Practitioner Guidance

What to verify: Confirm which directories are executable, which paths accept uploads or edits, and whether any JSP can reach administrative or diagnostic functions without a separate authorization check. Also verify that deployment users cannot modify production JSPs outside the controlled release process.

What to prioritise: Treat JSPs with file-write exposure, legacy scriptlets, or backend action handlers as high priority for review. If a page combines user input with server-side execution, review it before lower-risk presentation pages.

Common mistake: Teams often scan only for obvious XSS or broken layout issues and miss the more serious question of whether the page itself can be turned into executable server-side code.

Practitioner takeaway: The key security judgement is whether the JSP source is controlled like code, because once an attacker can alter it, the page stops being presentation logic and becomes an execution surface.

Related resources from NHI Mgmt Group

• Java Server Pages (JSP)
• Why do fake verification pages work so well against users?
• How should security teams prevent SSRF when applications render custom error pages from server-side requests?
• Why do server-side rendered applications with custom error pages increase SSRF risk in practice?