Sign up to save your podcasts
Or
Share Pill #3: Always Use Referrer-Policy Header
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Pill #3: Always Use Referrer-Policy Header
Hello and welcome back to Pills Dev - your bite-sized podcast for mastering software engineering fundamentals. I'm your host - Bartosz from Dev Academy - sharing quick tips on security, quality, and system design. To get more hot juicy tips visit pills dot dev.
Have you ever clicked "Remind me the password"? I bet you have. Did you know there is a serious security issue hidden behind it that most developers are unaware of? Let me explain.
Imagine you request a password reset. You receive an email with a password reset link, which often looks like this: application dot com slash reset question mark code equals one two three four five six. This code is unique to your password reset request. If the page contains some third-party code fetched from an external domain, this code might leak. In fact, any data from the URL may leak.
You might ask, how come? Look, if you load the page, then all the embedded parts load accordingly, sending proper HTTP requests. If you have some widget on the page that loads from, let's say, some dash widget dot com, the request loading that widget may contain HTTP Header Referer. The referer could be application dot com slash reset question mark code equals one two three four five six. So the secret token leaks. If you don't believe me, open your developer tools, and look for XHR requests on any website. You will find the Referer header with the original website address.
To prevent this URL data leakage, we need Referrer-Policy. This is one of the HTTP security headers that every developer should know. You can read the whole documentation about it, but here is a quick win. While serving your application, add an HTTP header: Referrer-Policy: origin-when-cross-origin. This will instruct the browser to send the origin, path, and query string only if the request points to the same origin, your internal link. If the request is cross-origin, only the sole origin is sent without the path and query string.
That's it for today. I hope it was useful. Thanks for tuning in and learning with me today. If you enjoyed this episode, consider subscribing so you won't miss tomorrow's exciting content!
View all episodes
By Bartosz | Dev AcademyHello and welcome back to Pills Dev - your bite-sized podcast for mastering software engineering fundamentals. I'm your host - Bartosz from Dev Academy - sharing quick tips on security, quality, and system design. To get more hot juicy tips visit pills dot dev.
Have you ever clicked "Remind me the password"? I bet you have. Did you know there is a serious security issue hidden behind it that most developers are unaware of? Let me explain.
Imagine you request a password reset. You receive an email with a password reset link, which often looks like this: application dot com slash reset question mark code equals one two three four five six. This code is unique to your password reset request. If the page contains some third-party code fetched from an external domain, this code might leak. In fact, any data from the URL may leak.
You might ask, how come? Look, if you load the page, then all the embedded parts load accordingly, sending proper HTTP requests. If you have some widget on the page that loads from, let's say, some dash widget dot com, the request loading that widget may contain HTTP Header Referer. The referer could be application dot com slash reset question mark code equals one two three four five six. So the secret token leaks. If you don't believe me, open your developer tools, and look for XHR requests on any website. You will find the Referer header with the original website address.
To prevent this URL data leakage, we need Referrer-Policy. This is one of the HTTP security headers that every developer should know. You can read the whole documentation about it, but here is a quick win. While serving your application, add an HTTP header: Referrer-Policy: origin-when-cross-origin. This will instruct the browser to send the origin, path, and query string only if the request points to the same origin, your internal link. If the request is cross-origin, only the sole origin is sent without the path and query string.
That's it for today. I hope it was useful. Thanks for tuning in and learning with me today. If you enjoyed this episode, consider subscribing so you won't miss tomorrow's exciting content!