Simple Ways to Secure Legacy Web Servers and Applications

How do you protect a legacy web application that cannot be upgraded this month? Remove direct access to its server, put a maintained access layer in front of the routes people still need, and set a deadline to replace or retire the unsupported components. A reverse proxy can help enforce that boundary. It does not patch the operating system or fix defects in the application.

Start with an inventory and risk assessment

Record the operating system and application versions, exposed ports and URLs, dependencies, data handled, users, and system owner. Identify which components still receive security updates and which do not. Prioritize systems with sensitive data, internet exposure, privileged connections, or known vulnerabilities. OWASP recommends inventory, risk assessment, access controls, monitoring, and a plan for maintaining legacy applications.

Choose a short-lived containment plan with an owner and review date. If a system cannot be isolated, logged, backed up, and tested, take that limitation to the business owner rather than describing the server as secured.

Isolate the origin before adding a proxy

Close public access to the old server. Permit inbound traffic only from the approved proxy or private network, restrict administrative access, and review outbound connections to other systems. Verify the origin cannot still be reached directly through an alternate address, port, or DNS name. Put authentication and authorization in front of the routes that need it; an encrypted connection alone does not restrict who can use the application.

Use a maintained reverse proxy for the web entry point

A current reverse proxy can present HTTPS to browsers, route permitted requests, apply request limits, and centralize some access controls and logs. Configure and test the origin connection separately. Browser to proxy encryption does not guarantee encryption or integrity on the proxy to origin hop. If the legacy application cannot support an appropriate transport, keep that hop on a tightly controlled private network and document the residual risk rather than calling the path end to end secure.

If your environment uses Microsoft IIS for the edge, see our IIS reverse-proxy setup guide. Treat it as a configuration starting point, then validate authentication, forwarded headers, origin isolation, and logging in your environment.

Where a cloud gateway fits, and where it does not

An API gateway can be useful for a defined API surface, but it is not a drop in security layer for every legacy website. Map the routes, methods, cookies, uploads, authentication flows, and dependencies first. Whether you use a gateway, reverse proxy, or private access service, the same rule applies: eliminate the direct path to the origin and test the allowed path end to end.

Apply controls that work while the application is still old

• Access: restrict users and service accounts to the work they actually need. Prefer an identity-aware access layer and multifactor authentication where the application cannot implement them safely itself. Test logout, session expiry, and privileged workflows.
• Traffic: use narrowly scoped rules or a WAF for known risky paths when there is evidence they help. Test allowed and blocked requests before and after the change. A virtual patch reduces exposure to a specific exploit path; it is not a code fix or a general guarantee.
• Detection: send proxy and application logs to a monitored destination. Alert on repeated failures, unexpected admin access, traffic to the origin, and suspicious changes. Keep a tested recovery path and an incident contact.

Validate the boundary before relying on it

From an untrusted network, confirm the origin and administrative ports are unreachable. From the approved route, test sign-in, session expiry, uploads, downloads, API calls, and error handling. Confirm the certificate and browser to proxy TLS configuration, then inspect how traffic reaches the origin. Check that logs include enough information for an investigation without exposing secrets. Record the results and the person responsible for each exception.

Set the exit condition

Containment buys time, not support from the original vendor. Give the system owner a review date and a funded path to upgrade, replace, or retire the application. If the app depends on obsolete authentication or a vulnerable runtime that the edge cannot compensate for, move the decision forward rather than adding another gateway. For the broader portfolio and sequencing decision, see our legacy application modernization strategy.

Need to decide whether a proxy is enough for a specific application? Tevpro can review the exposed routes, dependency risks, and modernization options with your team. Start with our legacy modernization services.