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. ...

In the previous article, you designed a search engine. Now let us wrap up this series with everything you need to ace a system design interview. This article is a cheat sheet and guide. Bookmark it and review before your interview. The 4-Step Framework Every system design interview follows the same structure. Use this framework to stay organized and cover everything the interviewer expects. 4-Step Framework (40 minutes total): Step 1: Requirements (5 minutes) - Clarify functional requirements (what the system does) - Clarify non-functional requirements (scale, latency, availability) - Define what is IN scope and OUT of scope Step 2: Estimation (5 minutes) - Users, traffic, storage - QPS (queries per second) - Peak vs average load Step 3: High-Level Design (15 minutes) - Architecture diagram - Core components and how they interact - API design - Data model Step 4: Deep Dive (15 minutes) - Interviewer picks 2-3 components to go deeper - Discuss trade-offs, failure modes, scaling - Show your knowledge of specific technologies Step 1: Requirements (5 Minutes) Do not skip this step. Jumping straight to the design is the number one mistake candidates make. ...

In the previous article, you designed a notification system. Now let us tackle one of the most complex systems in computing: a search engine. Search engines like Google index over 100 billion web pages and serve billions of queries per day. We will design a simplified version that covers the core components: crawling, indexing, ranking, and serving. Step 1: Requirements Functional Requirements Crawl the web and discover new pages Index page content for fast retrieval Search by keywords and return ranked results Autocomplete (search suggestions as you type) Return results in under 500ms Non-Functional Requirements Fresh results — new content indexed within hours Relevant results — best pages ranked first Scale to 100 billion indexed pages Handle 10 billion search queries per day High availability — search must always work Step 2: Estimation Indexed pages: 100 billion Average page size: 50 KB (text content after stripping HTML) Total index storage: 100B * 50 KB = 5 PB (raw text) Inverted index size: ~20% of raw text = 1 PB Queries: 10 billion per day QPS: 10B / 86,400 = ~115,000 queries/sec Peak QPS: ~350,000 queries/sec Crawling: New/updated pages per day: 1 billion Crawl rate: 1B / 86,400 = ~11,600 pages/sec Bandwidth: 11,600 * 100 KB (full page) = 1.16 GB/sec Step 3: Web Crawler The crawler discovers and downloads web pages. It is the first stage of the search engine pipeline. ...