Development

In the previous tutorial, you learned how to manage secrets safely. In this article, you will learn about HTTP security headers — simple response headers that tell browsers how to protect your users. Adding the right headers takes minutes and prevents entire categories of attacks. Why Security Headers Matter Security headers are instructions from your server to the browser. They say things like: “Only load scripts from my domain” (CSP) “Always use HTTPS” (HSTS) “Do not allow this page to be embedded in an iframe” (X-Frame-Options) Without these headers, browsers use permissive defaults that leave your users vulnerable. Adding headers is one of the highest-impact, lowest-effort security improvements you can make. ...

In the previous tutorial, you learned how to secure APIs with rate limiting and input validation. But the best API security means nothing if your secrets are hardcoded in source code. In this article, you will learn how to manage secrets properly — from .env files to production-grade vaults. The Problem: Secrets in Source Code Secrets are things like database passwords, API keys, JWT signing keys, and encryption keys. When developers hardcode them, bad things happen. ...

In the previous tutorial, you learned how CORS controls cross-origin access to your API. But CORS is just one layer. APIs are the most attacked surface in modern applications, and they need multiple defenses. In this article, you will learn rate limiting, input validation, and API authentication best practices. Why API Security Matters Every mobile app, SPA, and microservice communicates through APIs. If your API is insecure, everything built on top of it is insecure. ...

In the previous tutorial, you learned how CSRF attacks trick browsers into making unwanted requests. CORS is the browser’s mechanism for controlling which websites can make requests to your server. These two concepts are closely related, and developers often confuse them. What Is the Same-Origin Policy? Before we talk about CORS, you need to understand the same-origin policy. This is the browser’s most important security rule. Two URLs have the same origin if they share the same protocol, host, and port: ...

In the previous tutorial, you learned how HTTPS and TLS protect data in transit. But even with HTTPS, your application can be tricked into performing actions on behalf of a user — without the user knowing. This is called CSRF (Cross-Site Request Forgery). What Is CSRF? CSRF is an attack where a malicious website tricks your browser into sending a request to another website where you are already logged in. The browser automatically includes your cookies — so the server thinks the request came from you. ...

In the previous tutorial, you learned how to prevent SQL injection and XSS. Those attacks target your application logic. But there is another attack surface — the network. When data travels between your user’s browser and your server, anyone in between can read or modify it. Unless you use HTTPS. What is HTTPS? HTTPS is HTTP with encryption. It uses TLS (Transport Layer Security) to encrypt all data between the client and the server. ...

In the previous tutorial, you learned about authorization and access control. Now we tackle the two most common injection attacks: SQL injection and XSS (Cross-Site Scripting). Both fall under Injection in the OWASP Top 10 (A03 in the 2021 list, A05 in the 2025 update). Both have been around for over 20 years. And both are still in the top causes of data breaches — because developers keep making the same mistakes. ...

In the previous tutorial, you learned how to authenticate users — verifying who they are. But authentication alone is not enough. You also need authorization — controlling what they can do. Authentication answers: “Who are you?” Authorization answers: “What are you allowed to do?” Authentication vs Authorization Authentication Authorization Question Who are you? What can you do? When During login After login, on every request Method Password, JWT, biometrics Roles, permissions, policies Example “You are user Alex” “Alex can read posts but not delete them” A common mistake is checking authentication but skipping authorization. The user is logged in, so the app trusts them completely. This leads to Broken Access Control — the #1 risk in the OWASP Top 10. ...

In the previous tutorial, you learned the OWASP Top 10 security risks. Authentication failures (A07) are one of the most common. In this article, you will learn how to store passwords safely and implement token-based authentication with JWT. Why Passwords Are Still the #1 Target Despite all the advances in security, passwords remain the most common attack vector. Here is why: People reuse passwords across websites Weak passwords are easy to guess with brute force Many applications still store passwords incorrectly The LinkedIn breach in 2012 exposed 117 million passwords hashed with unsalted SHA-1. Attackers cracked most of them within days. The Adobe breach in 2013 exposed 153 million passwords encrypted (not hashed) with 3DES — all using the same key. ...

Most security breaches happen because of simple mistakes. A missing access check. An unvalidated input. A hardcoded password. In 2024, the average cost of a data breach was $4.88 million (IBM). Studies consistently show that human error is a major factor in security incidents. The good news? You do not need to be a security expert to write secure code. You just need to know what to watch for. This is the first article in the Security for Developers series. We will start with the OWASP Top 10 — the most widely used list of web security risks in the world. ...