Jetty is a Java web server and servlet container used to run HTTP applications and embed server functionality inside software. It implements web and servlet standards, so developers use it for hosting Java services, reverse proxying, and application integration.
What Jetty is used for in a Java stack
Jetty is a lightweight Java web server and servlet container that hosts HTTP applications and can also be embedded inside a larger program. That makes it useful both as an application runtime and as a building block for services, reverse proxies, and integration layers where teams want tight control over startup, packaging, and request handling.
Because Jetty sits on the network boundary, it often becomes part of the trust surface for an application rather than just a background library. How it is configured determines whether it behaves as a simple embedded component, a public-facing server, or a routing layer that forwards traffic to other internal services.
How Jetty fits web and servlet standards
Jetty implements the Java web and servlet model, so it provides the request-response machinery that Java web applications expect. In practice, that means it handles servlet lifecycles, HTTP listeners, routing to application code, and the integration points needed by frameworks that rely on the servlet API.
This standards alignment is what makes Jetty portable across many Java deployments. A service can run in an external Jetty instance, inside an application package, or as part of a platform that embeds Jetty to expose web endpoints without requiring a separate server process.
Why embedded Jetty changes deployment design
When Jetty is embedded, the server process and the application lifecycle are more tightly coupled. That can reduce operational friction, but it also means the application owner inherits responsibility for server startup, connector settings, shutdown behavior, and the exposure created by whatever ports and protocols the embedded instance opens.
Embedded use also changes upgrade and support patterns. A Jetty version may be bundled with an application, so server behavior can be governed by application release cycles rather than by a standalone infrastructure team. That coupling is convenient for packaging, but it can delay server-level changes when dependencies or deployment pipelines are slow to move.
Common operational patterns and where Jetty sits in the request path
Jetty is often chosen for direct web hosting, internal service hosting, and reverse proxy integration. In each case, its role is to accept HTTP traffic, apply the configured server behavior, and hand requests to the application or to another upstream destination.
That means Jetty is relevant to both application delivery and traffic control. If it is fronting a service directly, it may be the first point of contact for clients. If it is used behind another proxy or gateway, it still affects how requests are parsed, forwarded, and terminated, which makes its configuration part of the overall service architecture.
Risk and Threat Considerations
Jetty becomes security-relevant when it is exposed to untrusted network traffic, especially in embedded or reverse-proxy roles where its configuration governs what enters the application path. Misconfiguration, outdated components, weak access controls, or poor request handling can turn a normal runtime into an exposed edge service.
Failure mechanism: Attackers often look for web servers and servlet containers because they sit close to application logic and may expose admin surfaces, vulnerable endpoints, or trust boundaries that can be abused for request smuggling, denial of service, or application compromise.
Impact: A compromised Jetty deployment can expose the hosted application, disrupt availability, and create a foothold for deeper access into connected services, especially when the same runtime also carries internal credentials, session state, or proxy responsibilities.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Jetty defines a network boundary for HTTP traffic and proxying. |
| CM-6 — Configuration Settings | Jetty security depends heavily on connector, listener and deployment configuration. | |
| SI-2 — Flaw Remediation | Servlet containers need timely updates when vulnerabilities affect the runtime or bundled components. | |
| Recommendation — Constrain Jetty exposure with boundary controls and restrict inbound paths to required listeners. Standardise Jetty configuration baselines and review changes before release. Track Jetty updates and remediate affected deployments promptly. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Jetty hardening and deployment settings directly affect exposure and request handling. |
| CIS-7 — Continuous Vulnerability Management | Jetty versions and embedded dependencies must be monitored for exposure to known flaws. | |
| Recommendation — Harden Jetty deployments with approved secure configuration standards. Continuously inventory Jetty deployments and prioritize remediation of known vulnerabilities. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-Rest is Protected | Jetty-hosted applications may process sensitive data that needs protection during storage and handling. |
| PR.PS-04 — Software Is Patched or Replaced | Jetty deployments depend on timely patching and replacement of vulnerable runtime versions. | |
| Recommendation — Protect stored application data handled by Jetty-backed services according to policy. Patch or replace vulnerable Jetty builds before they remain exposed in production. | ||
Practitioner Guidance
Why practitioners should care: Jetty is not just a library choice, it is part of the service boundary, so ownership should include configuration review, version management, and clarity on whether it is acting as a server, an embedded component, or a traffic intermediary.
What to watch for: Pay particular attention to internet exposure, connector settings, administrative interfaces, and how Jetty is packaged into the application lifecycle. Those details determine whether the server is safely isolated or effectively exposed as part of the application itself.
Practitioner takeaway: Treat Jetty as an operational control point, not only as an implementation detail, because its deployment model shapes both attack surface and change management.
Related resources from NHI Mgmt Group
- How should teams configure JMX monitoring for Jetty in OpenTelemetry environments?
- Why does Jetty session and thread telemetry matter for operational monitoring?
- What are the signs that Jetty metrics collection is not capturing useful signal?
- What is the difference between Jetty select count and Jetty session count?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org