In this video, learn about the role of transport security in HTTP responses and the header used to specify it.
- [Instructor] Part of a website's origin is the protocol. In the early days of the web, HTTP was the standard protocol used for all communications. Using HTTP request and response data is theoretically viewable by anyone, between the client and the server. Like the information on a postcard would be while en route from sender to recipient. When the need arose for more secure communication on the web, for requests and responses involving sensitive information like credit card numbers. A version of HTTP using encryption was implemented. Using the protocol HTTPS. With HTTPS requests and response date is encrypted before transmission, and decrypted after receipt. With ensures it can't be read or altered in transit. This is more like sending a letter through the mail, sealed in an envelope. HTTPS sets up a secure channel between client and server, allowing requests and responses to be encrypted before transmission. This prevents what's known as a man in the middle attack, in which a third party intercepts communications. And potentially changes them en route. Today this protocol is used for much of web traffic. Web services are increasingly switching to use HTTPS exclusively, to ensure that users web browsing can not be casually monitored. As part of the scheme known as HTTP Strict-Transport Security, or HSTS. A web service can request that browsers enforce the use of HTTPS when communicating To do this they send a strict-transport security header with a response to a client. When a serve using this header receives a request for a resource, it replies with this header. However, what the browser does with this information depends on a couple factors. If the users original request, the URL entered or the linked clicked specified HTTPS as the protocol. Then the browser logs the fact that this web service should use only HTTPS connections. And any future requests to this service will be sent as HTTPS requests by that browser. Even if the URL entered or the link clicked is only HTTP. However, if a users initial visit to the service involves entering a URL or clicking a link that uses the HTTP protocol, then the browser ignores the strict transport security directed in the response. The reason for this is that because the original request was not encrypted, the browser can't be sure that the information in the response was not tampered with en route. The reason for this is that because the original request was not encrypted, the browser can't rely on the information in the response. It's possible that a tampered request could redirect the browser to an imposter site, and the tampered result should not be set as the browser default for future requests. Instead the strict-transport security directive is honored only when a users initial request to the web service happens via HTTPS. At that point, the directive is applied to all future visits.
- Working with browser security features
- Configuring servers for testing
- Defining an origin
- Cross-site scripting attacks
- Cross-site request forgery attacks
- Working with a received message
- Specifying the allowed message sender origin
- Sharing cookies across subdomains
- Restricting the path of a cookie