I want to understand how the flow between IIS and Kestrel works with regards to security. It seems that the integration between IIS and Kestrel is that IIS just sends absolutely all that it receives to Kestrel, be it valid HTTP request or not. IIS does handle the SSL though, so it's quite transparent for Kestrel.

So I have a question: does that mean that with the exception of SSL, security is handled by Kestrel? So all potential vulnerabilities in IIS are pretty much not possible or easy to exploit? Like e.g. a bug that allowed to get the web.config some time ago from IIS would only be possible to abuse if Kestrel has the similar type of bug.

1 Answer 1


The simple answer is: both. They have different roles and manage different security functions, but there are some aspects of security that each must handle.

In this model, IIS is operating as a reverse proxy, and Kestrel is the application web server. Reverse proxies (IIS and otherwise) often are responsible for more than simply dumb routing. As you've noted, if you're using HTTPS, termination happens at the IIS layer. IIS may also serve other functions, such as compression and caching, just as any reverse proxy might. It also continues to need web.config, in order to find out what that configuration is. Each of these functions has some number of security implications that need to be kept in mind.

Application specific security functions, like most authentication and authorization, input and output encoding, and other application specific functions will be handled within the application execution pipeline and environment inside Kestrel, as you expect.

So, while the role of IIS in security is greatly reduced in this model, it isn't eliminated entirely.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .