Web and App Servers
Takes web requests, then runs the app or passes them to the server that does.
What It Is
A web server takes requests from the network and gets an answer back to the browser. Some web servers only pass requests on. When nginx sits in front of an app, it is a reverse proxy. It handles the connections and the encryption, then hands each request to the server behind it without ever running the app's code.
An app server runs the application's code and answers the requests a front end hands it. Gunicorn does this for Python apps such as Django, Puma for Ruby on Rails, PHP-FPM for PHP and Tomcat for Java. Apache and IIS can do both jobs. Apache can run PHP in its own processes, and IIS runs ASP.NET apps in its worker processes.
So a common set-up is two servers in a row. nginx faces the internet and passes each request to Gunicorn, which runs Django on Python. Which of the two only passes requests on, and which runs the code, decides how far a flaw in each one reaches.
- App
- Framework
- Web Server
- Runtime
- Containers
- OS
- Hypervisor
- Firmware
- Hardware
- Data
On This Layer
These are the technologies on the Web and App Servers layer that this topic covers. Open one to see what it runs on, how to spot it and what a flaw in it reaches.
- IISMicrosoft's web server, built into Windows Server.
Apache HTTP ServerA long-established open-source web server.
nginxA fast web server and reverse proxy.
TomcatA web server that runs Java web applications.
GunicornA Python app server that runs Django and Flask apps behind a front end such as nginx.
PumaA Ruby app server that runs Rails apps, often behind a front end such as nginx.- PHP-FPMPHP's own process manager, which runs PHP code for a front end such as nginx.
How Far a Flaw Reaches
A flaw in a server that runs the app's code reaches every app it runs. A flaw in a front end that only passes requests on puts that traffic at risk. Whoever holds the flaw could read or change requests on their way through, but could not run code in the apps behind it.