I’ve been a web developer for more than 25 years, and I have always loved the flexibility of HTTP servers: IIS, Apache, Nginx, Node.js etc. But in my last 5-10 years I’ve also struggled with them in terms of how they often lack in securing my web applications - a bit like the feeling, that they are better at serving than protecting my applications.

So this idea has been turning in my head for a couple of years without any real progress.

HTTP servers can handle a lot of different types of requests and also supporting a large variety of programing languages, .NET, PHP, JavaScript etc. for server-side programming. But none of them really care about the limited types of requests my web applications are developed to support.

So I typically have to guard all that with a separate application gateway server or reverse proxy where I can configure my security and validation of incoming requests - and I’ve started to wonder why is that???

Why isn’t HTTP servers built the other way round that they by default don’t let anything through (like firewalls typically go about it) and then the web application and configuration has to open up the types of requests what the application is supposed to serve?

Shouldn’t we as webdev’s maybe raise this question (requirement) to the HTTP Server developers?

Just imagine that you could load your web applications URL’s with their respective GET, HEAD and POST HTTP methods into their valid serving requests memory and that would then be the only types of requests they would serve and just block anything else out of my applications responsible to error handle and use CPU and Memory to deal with not even to mention logging!