Pills.DEV

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!

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. Today, let's talk about a common web security threat called clickjacking and how to prevent it. Imagine this scenario: you have built an amazing website with features that make users happy and they feel safe using it. Then one day, you discover your system is vulnerable to clickjacking. What does this mean? Well, here's the situation: A user visits a malicious website with a tempting button, like "You won one hundred dollars." This website embeds your website in an invisible iframe. When the user clicks the button, they unknowingly click on your website, performing actions on your site as if they were logged in. Scary, right? Here's how clickjacking works: The malicious site positions your site in such a way that when the user clicks, the action happens on your site instead. This could result in liking a post, sending a message, or even transferring money. But don't worry. There's an easy way to protect your site from this kind of attack. You need to send proper HTTP headers while serving your website. The first option is using the X-Frame-Options header. You can set its value to DENY, which prevents any website from embedding your site, or to SAMEORIGIN, which allows only your domain to embed it. Another option is to use the Content Security Policy with the frame-ancestors directive. This allows you to specify which origins can embed your site or to deny embedding entirely. In summary, preventing clickjacking is straightforward. Just use the correct HTTP headers, such as X-Frame-Options or Content Security Policy, to ensure your website cannot be embedded in an iframe by an untrusted source. 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!

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. Today, let's delve into the world of web security, focusing on JSON Web Tokens, commonly known as JWTs. You might have heard that JWTs are a golden standard, often considered a more modern solution compared to traditional session cookies. But, let's set the record straight, JWTs aren't necessarily better, they're just different, each with its own set of advantages and drawbacks.Here's a critical point to consider, the security of a JWT hinges on its cryptographic signature, which depends on a secret key known only to your server. Now, imagine this key is simple or too short. It becomes an easy target for brute force attacks where attackers use powerful cloud computing to guess this key. Once they crack it, they can impersonate any user by generating valid tokens. That sounds like a nightmare, doesn't it?But there is a straightforward solution. Use a strong secret key. For instance, if you're using HS256 for token signing, your key should be at least 32 bytes long, ensuring that a brute-force attack could take centuries with current technology.In summary, while JWTs can be useful, they require careful handling to ensure they are secure. Always opt for strong, complex keys to protect your applications from potential attacks. 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!