Security

A Kubernetes cluster has many attack surfaces. Misconfigured Pods can break out of their namespace. Overprivileged service accounts can access the entire cluster. Unscanned images can run with known vulnerabilities. This tutorial covers the essential security practices before taking any Kubernetes application to production. The 4Cs of Cloud Native Security Think of Kubernetes security in layers: Cloud → Cluster → Container → Code Code — vulnerabilities in your application code Container — image security, running as non-root, minimal base images Cluster — RBAC, Pod Security Standards, Network Policies Cloud — network firewall rules, IAM policies, cloud provider security Each layer depends on the one below it. Fixing only one layer is not enough. This tutorial focuses on the Container and Cluster layers. ...

You built the app. It works. But before you ship it, you need to think about security. Can someone decompile your APK and read your code? Is the user’s data safe? Can a man-in-the-middle attack steal API tokens? In this tutorial, you will learn how to protect your Android app — from code shrinking with R8 to biometric authentication and encrypted storage. Prerequisites: You should have a working Android app. If you have been following this series, you already have everything you need. ...

Most beginner Docker setups have serious security problems. Containers running as root. Passwords in Dockerfiles. Outdated base images with known vulnerabilities. No resource limits. This tutorial covers the most important Docker security practices. You do not need to implement all of them at once. Start with the first three — they will fix the most critical issues. 1. Never Run Containers as Root By default, processes inside Docker containers run as root (UID 0). If an attacker exploits a vulnerability in your app, they have root access inside the container — and potentially a path to the host. ...

Every time you see the padlock in your browser, two computers perform a secret handshake. They agree on a secret key — without ever sending that key across the internet. And your browser checks that the server really is who it claims to be. This post explains exactly how that works: HTTPS, the TLS handshake, keys, and certificates. In simple steps. The Problem: Plain HTTP Is Readable HTTP sends everything as plain text. Your password, your messages, your card number — all of it. ...

Your API has authentication, but that is only one layer of security. Without rate limiting, attackers can brute-force passwords. Without CORS, any website can call your API. Without security headers, your application is vulnerable to clickjacking and XSS attacks. In this tutorial, you will add three essential security features: CORS configuration, rate limiting, and security headers. These are requirements for any production API. Why These Security Features Matter CORS → Controls which websites can call your API Rate Limiting → Prevents brute-force attacks and abuse Security Headers → Prevents clickjacking, XSS, and MIME sniffing Dependencies Add the Ktor security plugins: ...

In the previous tutorial, you added JWT authentication. Users can register, login, and access protected routes. But the implementation was basic. There were no refresh tokens, no password validation, and no logout. In this tutorial, you will build a complete authentication flow. You will add refresh tokens with rotation, strong password validation, email validation, and a logout endpoint that revokes tokens. What We Will Build Here is the complete auth flow: ...

Your API works. It has routes, a database, file uploads, and migrations. But anyone can access any endpoint. There is no authentication. In this tutorial, you will add JWT (JSON Web Token) authentication. Users will register, login, get a token, and use that token to access protected routes. How JWT Authentication Works JWT authentication follows this flow: 1. Client sends email + password → POST /api/auth/login 2. Server verifies credentials 3. Server generates a JWT token 4. Server sends token to client 5. Client stores token 6. Client sends token with every request → Authorization: Bearer <token> 7. Server verifies token and processes request The token contains encoded information (claims) about the user. The server can verify the token without a database query. ...

This is the final article in the Security for Developers series. It brings everything together into a single, actionable checklist you can use for every project. Bookmark this page and review it whenever you start a new project or prepare for a security review. How to Use This Checklist Each item is marked with a priority level: P0 (Critical): Do this before going to production. Skipping it means you are vulnerable. P1 (High): Do this within the first week of production. Important for security posture. P2 (Medium): Do this within the first month. Improves defense in depth. P3 (Low): Nice to have. Do when you have time. Authentication Checklist # Item Priority Details 1 Hash passwords with bcrypt or Argon2 P0 Never store plaintext. Use cost factor 12+ for bcrypt. 2 Enforce minimum password length of 8 characters P0 NIST recommends 8+ characters. Do not require special characters. 3 Use HTTPS for all authentication endpoints P0 Credentials in transit must be encrypted. 4 Implement account lockout after failed attempts P1 Lock after 5-10 failed attempts for 15-30 minutes. 5 Use JWT with short expiration (15-60 min) P1 Combine with refresh tokens for longer sessions. 6 Sign JWTs with RS256 or EdDSA (not HS256 for distributed) P1 Asymmetric signing prevents key sharing. 7 Store tokens in httpOnly cookies (not localStorage) P1 Prevents XSS from stealing tokens. 8 Implement refresh token rotation P1 Invalidate old refresh token on each use. 9 Validate JWT signature and expiration on every request P0 Never trust a token without validation. 10 Support multi-factor authentication (MFA) P2 TOTP or WebAuthn. SMS is better than nothing. 11 Check passwords against breached lists (Have I Been Pwned) P2 Reject passwords that appear in known breaches. 12 Log all authentication events P1 Successful and failed logins, password changes. Reference: Tutorial #2: Authentication ...

In the previous tutorial, you learned about security logging and monitoring. Now let us secure where your code runs. Docker containers are everywhere, but the default configuration is not secure enough for production. In this article, you will learn how to harden Docker containers, scan images for vulnerabilities, and manage secrets safely. Why Container Security Matters Containers provide isolation, but they are not virtual machines. By default: Containers run as root — if an attacker breaks out, they have root on the host Docker images contain hundreds of packages, many with known vulnerabilities Secrets are often baked into images or passed as environment variables (visible in process lists) Network ports are exposed by default — more attack surface A compromised container can lead to: ...

In the previous tutorial, you learned how to scan dependencies for vulnerabilities. But what happens when an attack is already in progress? Without proper logging and monitoring, you will not know until it is too late. In this article, you will learn what to log, what never to log, how to detect attacks, and how to set up meaningful alerts. The OWASP Top 10 lists “Security Logging and Monitoring Failures” as A09 because most breaches go undetected for months. ...