Security is a major concern when designing any API. In this video, learn the difference between transport and application security, and explore the security best practices you should follow.
- [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.
- What is RESTful design?
- Building a new API with ASP.NET Core
- Using HTTP methods
- Returning JSON
- Creating RESTful routing with templates
- Securing RESTful APIs with HTTPS
- Representing resources
- Representing links
- Representing collections
- Sorting and searching collections
- Building forms
- Adding caching to an ASP.NET Core API
- Configuring user authentication and authorization
Skill Level Advanced
1. REST API Concepts
2. Build a Basic API
3. Versioning and Errors
4. Secure the API
5. Represent Resources
6. Represent Links
7. Represent Collections
Add pagination7m 37s
8. Sorting Collections
9. Searching Collections
10. Forms and Modifying Data
11. Caching and Compression
12. Authentication and Authorization
- Mark as unwatched
- Mark all as unwatched
Are you sure you want to mark all the videos in this course as unwatched?
This will not affect your course history, your reports, or your certificates of completion for this course.Cancel
Take notes with your new membership!
Type in the entry box, then click Enter to save your note.
1:30Press on any video thumbnail to jump immediately to the timecode shown.
Notes are saved with you account but can also be exported as plain text, MS Word, PDF, Google Doc, or Evernote.