Table of Contents
- When is
Authorizationheader sent by the browser?
- Basic access authentication
- Cache Control
- Cookies vs Web Storage
- Misspelling of Referrer
- There are some tricky parts when requesting between HTTPS and HTTP (detail)
when a user clicks a hyperlink in a web browser, the browser sends a request to the server holding the destination webpage. The request includes the referer field, which indicates the last page the user was on (the one where they clicked the link).
Authorization header sent by the browser? discussion
Only types like
Authorization header is sent automatically by browser in following cases:
Authorizationheader field allows a user agent to authenticate itself with an origin server – usually, but not necessarily, after receiving a 401 (Unauthorized) response.
On the other hand, other types must explicitly be added by
Bearertoken in the
Basic access authentication discussion
Because the BA field(
Authorization: Basic) has to be sent in the header of each HTTP request, the web browser needs to cache credentials for a reasonable period of time to avoid constantly prompting the user for their username and password. Caching policy differs between browsers. Microsoft Internet Explorer by default caches them for 15 minutes.
Acceptheader is used by HTTP clients to tell the server what content types they'll accept. The server will then send back a response, which will include a
Content-Typeheader telling the client what the content type of the returned content actually is.
Content-Type header on HTTP Request is for the payload of
PUT, which tells the server how the payload is formed.
Cache Control discussion
Cache-Control: max-age=<seconds> Cache-Control: max-stale[=<seconds>] Cache-Control: min-fresh=<seconds> Cache-Control: no-cache Cache-Control: no-store Cache-Control: no-transform Cache-Control: only-if-cached
Cache-Control: must-revalidate Cache-Control: no-cache Cache-Control: no-store Cache-Control: no-transform Cache-Control: public Cache-Control: private Cache-Control: proxy-revalidate Cache-Control: max-age=<seconds> Cache-Control: s-maxage=<seconds>
Yes, as long as the URL requested is within the same domain and path defined in the cookie (and all of the other restrictions – secure, httponly, not expired, etc) hold, then the cookie will be sent for every request.
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
- The cookies that are set can only be sent over HTTPS
- The cookies that are set cannot be retrieved with JS. Only be sent to the designated server.
Cookies vs Web Storage discussion
Does your auth token protect anything to do with money?
- You'll probably want the cookie
- By using
Is the level of effort required to implement CSRF protection not worth the assets it's protecting?
- Then the Web Storage might be the right place.
Disadvantages compared to Web Storages:
4KBof max size (it counts all elements like name, value, expiry date)
There are two types of Web Storage:
- data persists until explicitly deleted.
- Once the window is closed, the storage is deleted.
Web Storage is safe from CSRF attacks, since it doesn't automatically send its contents.
However, there are some disadvantages compared to Cookies:
- sandboxed to a specific domain
- accessible through JS, which means that it's vulnerable to XSS attacks