# Separate your public web edge from the application

> Give the web server, reverse proxy and application distinct responsibilities, with deliberate origin access, TLS, request limits and an incident path.

Canonical human page: https://swissoctet.com/insights/separate-the-web-edge-from-the-app/

SwissOctet Editorial. Topic: hosting. Level: Applied. Reading time: 4 minutes.

## Direct answer
Separate HTTP publication from application execution and persistent data. A reverse proxy can organise routing and limits, but origin access, application authorisation, upstream capacity and recovery each require their own controls.

## A web request crosses several responsibilities
A web server receives HTTP requests and can serve static files. An application process executes the project's dynamic behaviour, such as checking an account or querying a database. A reverse proxy receives requests on behalf of that process and forwards them to an upstream. One program may fulfil several roles, but separating the responsibilities makes configuration and recovery easier to reason about.

Trace one request from hostname resolution to the response. Record where TLS ends, which process chooses the route and which component can read application data. Do the same for an administrative request. This exercise often exposes a listener or hostname that was created for testing and accidentally remained reachable. The diagram should describe the deployed path rather than the architecture you hoped to build.

## Use the edge to organise HTTP behaviour
NGINX documents both serving static content and forwarding requests to an upstream. Its worker architecture and HTTP modules provide configuration mechanisms, but a particular configuration still determines the behaviour. Define hostnames, upstreams and filesystem roots deliberately. Restrict the files that can be served so configuration, credentials and repository metadata never become downloadable because they happen to sit near the application.

Set appropriate limits for request bodies, timeouts and connections according to the application. Treat caches as a data decision: content tied to a user or permission cannot safely inherit a shared caching rule without review. Test authentication and cache behaviour together. Keep a reproducible configuration and validate changes before reloading the service, with a known route back to the previous working version.

| Layer | Useful responsibility | Check before launch |
| --- | --- | --- |
| Public web edge | TLS, hostname routing and HTTP limits | Certificates, roots and intended hostnames |
| Application process | Business logic and authorisation | Authentication, input checks and dependency failure |
| Internal data service | Persistent application state | Restricted access and tested restoration |
| Upstream provider network | The contracted network service | Protection scope and escalation path |

## A reverse proxy does not remove the origin's exposure
If the origin remains publicly accessible, a client may reach it without using the intended proxy route. Restrict origin access through the network design and application configuration when the deployment requires that boundary. On one machine, a backend can often listen on loopback or a local socket. Across machines, use explicit restricted routes and suitable protection for the upstream connection.

Forwarded headers need a trust rule too. Accept information about the original client only from trusted intermediaries, and prevent arbitrary callers from supplying values that the application treats as authoritative. Decide what appears in access logs and error reports. A proxy can change the information available at each layer; it does not erase account identifiers or make the application anonymous to its own operator.

## Apply access decisions inside the application
NIST's Zero Trust architecture focuses on access decisions for resources rather than implicit trust based only on network location. Apply that principle concretely: authenticate the caller, authorise the requested operation and give service accounts only their required scope. A request arriving from an internal subnet should not automatically become an administrator request.

Separate public and administrative functions where practical. Recheck permission when a user accesses a record rather than relying only on the initial login. Keep credentials for the proxy, application and database distinct. Introduce changes in stages that can be tested, beginning with a narrow sensitive path. Calling a deployment Zero Trust is less useful than demonstrating that a forbidden action is actually denied at the component responsible for it.

## Plan denial of service at more than one layer
A saturated network link and an expensive application request fail at different places. Rate limiting at the web edge may help constrain request patterns, while application limits can bound work such as searches, uploads or exports. NGINX's request-limit module supplies one mechanism; the key and thresholds must fit real users and be tested to avoid rejecting legitimate traffic.

OWASP's denial-of-service guidance also addresses resource exhaustion in application behaviour. Put time and size limits around expensive work, use bounded queues and monitor failure signals. Local controls cannot create capacity in an upstream link that is already saturated. Confirm the specific network protection included in the chosen offer and prepare an escalation path. Never assume a catalogue's Layer 3–4 protection also proves protection for every HTTP workload.

## Make recovery part of the publication
Check the site from an external client using its intended hostname. Verify HTTPS, redirects, static resources, logins and a representative application transaction. Confirm that administrative listeners and private files remain inaccessible. Simulate a stopped upstream and check that the edge returns a controlled failure rather than exposing internal details or waiting without a limit.

For Canvas, read the controls available within the hosting account. For a VPS, maintain the web edge and application as part of your own operating plan. A large network port is a capacity specification, not proof that the application can sustain that throughput. Keep monitoring, restoration and provider contacts in the runbook. Publish only after the actual request path and a practical recovery path have been verified.

## Checklist
- Trace a public and an administrative request.
- Define served roots and upstream listeners.
- Trust forwarded headers only from approved intermediaries.
- Test authorisation and cache boundaries.
- Prepare limits and escalation for network and application failures.

## Frequently asked questions
### Can a web server also act as a reverse proxy?
Yes. NGINX is one documented example. Its roles depend on the configuration, and the application still needs its own authorisation and maintenance.

### Does a reverse proxy automatically hide the origin?
No. The origin may remain reachable unless routing, firewall and listener settings enforce the intended boundary.

### Will request limiting stop every DDoS attack?
No. It addresses selected HTTP request patterns. Network saturation and other resource failures require appropriate upstream and application controls.

## Primary sources
- [NGINX: Beginner's guide](https://nginx.org/en/docs/beginners_guide.html)
- [NGINX: HTTP request limiting](https://nginx.org/en/docs/http/ngx_http_limit_req_module.html)
- [NIST SP 800-207: Zero Trust Architecture](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf)
- [OWASP: Denial of Service Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html)

## Related infrastructure
- [Canvas Web](https://swissoctet.com/services/canvas/index.txt): A clean foundation for websites and publishing. Pick your storage, domains and hosting options.
- [Vector VPS](https://swissoctet.com/services/vector/index.txt): Your own Linux environment, with KVM virtualization and a clear path from small projects to larger workloads.
- [Pulse NVMe](https://swissoctet.com/services/pulse/index.txt): Fast NVMe storage for applications where I/O is part of the performance equation.
- [Transit 40](https://swissoctet.com/services/transit-40/index.txt): Dedicated configurations with a 40 Gbps port for bandwidth-intensive applications.

## Related guides
- [A Linux VPS hardening baseline you can maintain](https://swissoctet.com/insights/linux-vps-hardening-baseline/index.txt): Secure administration, expose only required services and establish updates and recovery without locking yourself out.
- [Build monitoring that leads to a useful incident response](https://swissoctet.com/insights/monitoring-incident-response-playbook/index.txt): Connect application symptoms, actionable alerts and a small response playbook so that an operator can make clear decisions when a service degrades.
- [A domain, DNS and TLS cutover runbook for a new server](https://swissoctet.com/insights/dns-tls-cutover-runbook/index.txt): Prepare hostname routing, certificates and rollback together so that a migration changes the server without breaking the site's identity or secure connections.