From the course: Building and Securing RESTful APIs in ASP.NET Core

Transport security in ASP.NET Core - ASP.NET Core Tutorial

From the course: Building and Securing RESTful APIs in ASP.NET Core

Start my 1-month free trial

Transport security in ASP.NET Core

“

- [Narrator] Security is a major concern for any application or API today and it's crucial to consider security early on in the development of your API. It's much easier to design security in from the beginning rather than trying to bolt it on at the end. There are two major types of security you'll need to consider. The first is transport security, which means keeping the connection between the client and the server secure. The second is application security, which covers things like authentication and making sure that users are authorized to perform certain actions in your system. We'll examine transport security in the Landon Hotel API first. Later, we'll round out the security story by adding application security in the form of authentication and authorization. There are a few elements of transport security we can add to the API. The first and foremost is HTTPS. ASP.NET Core uses HTTPS by default, which means clients will be able to connect to the API with an encrypted connection. The default behavior in ASP.NET Core is to redirect any HTTP traffic to HTTPS. We can take this a step further by forcibly rejecting any unencrypted connection attempts instead of redirecting. This is more secure because it prevents clients from accidentally leaking information if they mistakingly connect over HTTP instead of HTTPS. ASP.NET Core applications typically run on the Kestrel web server, and Kestrel can either be deployed directly to the public internet or in combination with a reverse proxy like IIS or NGINX. Installing a certificate and configuring HTTPS is done at the reverse proxy layer if you're using one, or as part of Kestrel's configuration. The API template you used to create the initial project already configured IIS Express as the reverse proxy with a local development certificate so you can use HTTPS on your dev machine. Rejecting unencrypted HTTP requests should also be done at the reverse proxy layer, if possible. I'll show you how to add additional enforcement at the application level as well. One other aspect of transport security worth discussing is the HTTP Strict Transport Security header, or HSTS. The HSTS header is returned by your server and instructs web browsers to prevent the user from accidentally connecting over HTTP. Once browsers see the header return from a given site, they will refuse to connect unless the connection is HTTPS. If your API clients include browsers, you could consider returning this header. However, if you've already followed the recommendation of rejecting all HTTP requests in the first place, the value of returning the HSTS header is probably marginal. In a single-page app scenario where a browser makes request to your API, you can further restrict outgoing requests with the proper Content Security Policy on the site. That being said, ASP.NET Core projects come with HSTS on by default and leaving it on isn't likely to hurt anything as long as you're aware of it. In the default template, the use HSTS middleware is turned on by default if you're running in a production environment. This helps make sure that you don't accidentally tell your browser to require HTTPS for local paths like local host. Next, I'll take a look at the other default transport security settings in ASP.NET Core and show you how to lock them down even further.

Contents