Security Essentials

Use parameterized queries (prepared statements). Never concatenate user input into SQL strings. In Python: cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,)) — not f"SELECT * FROM users WHERE id = {user_id}". ORMs (SQLAlchemy, Hibernate) use parameterized queries by default. Additionally: a least-privilege DB user (the app user can only SELECT/INSERT, never DROP), a WAF to block obvious attack patterns, and input validation to reject obviously invalid data early.

For most web apps: HttpOnly, Secure, SameSite=Strict cookies holding opaque session IDs stored in Redis. Reasons: XSS cannot steal HttpOnly cookies; SameSite prevents CSRF without extra tokens; the server can instantly revoke sessions (delete from Redis); and no data is exposed (a JWT payload is readable by anyone). JWT shines when: (1) statelessness is required (no shared session store across services), (2) tokens must cross domains or reach mobile apps, (3) you run a short-TTL access token + refresh token flow. Microservices often use JWT internally — service A includes the user's JWT when calling service B, which verifies it without hitting the auth DB. Just keep expiry short (15 min), use refresh tokens, and rotate signing keys regularly.

(1) Authentication: OAuth 2.0 Authorization Code + PKCE for mobile (no client_secret possible); Client Credentials for server-to-server third parties. (2) Authorization: scopes in OAuth tokens (read:users, write:orders), enforced at the API gateway. (3) Rate limiting: per API key, tiered — free at 100/min, paid at 10K/min. (4) Input validation: validate everything, reject early. (5) HTTPS only with an HSTS header. (6) Versioning: /v1/, backward-compatible changes only. (7) Logging: every request with client_id, endpoint, response code, latency — but never request bodies that may contain PII. (8) Secrets rotation: API keys must be rotatable without service disruption.

Encryption transforms data into unreadable ciphertext that can be reversed (decrypted) with a key. It exists to protect confidentiality. There are two families: symmetric encryption uses the same key for both operations (e.g., AES — fast, suitable for bulk data), and asymmetric encryption uses a public key to encrypt and a private key to decrypt (e.g., RSA — slower, used for key exchange and digital signatures). Encryption is reversible if you hold the key.

Hashing generates a fixed-size, irreversible digest from input data. It is a one-way function — the same input always produces the same output, but you cannot reconstruct the input from the hash. A small change in input produces a completely different hash (the avalanche effect). Hashing is used for integrity checks and password storage (e.g., bcrypt, Argon2, SHA-256 with salt). It is not reversible by design.

Summary: use encryption when you need to retrieve the original data; use hashing when you only need to verify identity or integrity without ever recovering the plaintext.

Asymmetric encryption (RSA, ECC, DSA) relies on computationally hard mathematical problems — for example, RSA uses modular exponentiation over very large primes (2048-bit or 4096-bit keys). These operations are CPU-intensive and cannot be easily hardware-accelerated at the same throughput as symmetric ciphers.

Symmetric encryption (AES) uses a single shared key and operates on data blocks with efficient bitwise and substitution operations. Modern CPUs have dedicated AES-NI instructions that make AES extremely fast — orders of magnitude faster than RSA for the same data volume.

The real-world solution is hybrid encryption: TLS/HTTPS uses asymmetric encryption only during the handshake to securely exchange a symmetric session key, then switches to fast symmetric encryption (AES-GCM) for the actual data stream. This gives you the security properties of asymmetric key exchange with the performance of symmetric encryption.

PKI (Public Key Infrastructure) is a framework of roles, policies, and technologies that enables secure authentication, encryption, and digital signing over untrusted networks like the internet. It answers the critical question: "How do I know this public key really belongs to example.com?"

PKI builds trust through a chain of trust: browsers ship with a set of pre-trusted Root Certificate Authorities (CAs). Root CAs sign Intermediate CA certificates, which in turn sign the leaf certificate for your domain. If the browser trusts the root, it trusts the entire chain down to your certificate. Each digital certificate binds a public key to an identity (domain, organization) and includes the issuer's signature, validity period, and allowed usages.

When a browser visits an HTTPS site, it verifies the certificate's signature, expiration, and issuer against the trusted chain. It also checks revocation status via CRLs (Certificate Revocation Lists) or OCSP (Online Certificate Status Protocol) to catch compromised certificates. PKI ultimately provides: Authentication (you're talking to the real server), Confidentiality (encrypted session), Integrity (tamper detection), and Non-repudiation (signed content cannot be denied).

Data at Rest refers to data stored persistently — on disk, SSDs, databases, file systems, and backups. Threats include physical theft of storage media, compromised database access, and insider threats. Protection methods include full-disk encryption (BitLocker, LUKS), database-level encryption (Transparent Data Encryption / TDE), file-level encryption, and strict IAM roles enforcing least-privilege access. Encryption keys themselves must be managed via a KMS (Key Management Service) rather than stored alongside the data.

Data in Motion (data in transit) refers to data actively moving through the network — between client and server, between microservices, or across data centers. Threats include eavesdropping, MITM attacks, and session hijacking. Protection methods include TLS/SSL (HTTPS for client-server, secure WebSockets), VPNs and IPSec for internal network tunnels, and mutual TLS (mTLS) for service-to-service communication where both sides present certificates.

A robust security posture encrypts data everywhere — at rest and in transit — and combines encryption with strong access controls, auditing, and continuous monitoring. Leaving one state unprotected breaks the entire chain.

Use OAuth 2.0 / OpenID Connect for delegation and identity federation. A dedicated Authentication Server (Auth0, Okta, or a custom implementation) issues short-lived access tokens (~15 min) and longer-lived refresh tokens stored securely server-side or in HttpOnly cookies. Tokens are typically JWTs signed with HMAC-SHA256 or RSA, enabling stateless validation across services without querying a central session store.

Security layers to add on top: enforce HTTPS everywhere so tokens are never transmitted in plaintext; implement MFA for sensitive operations; rate-limit login attempts to prevent brute force; rotate signing keys on a schedule; and set short token TTLs with forced re-authentication for high-risk operations (e.g., password change, large financial transfers). Store minimal session state on the client — only what is needed for the token to be self-describing.

The CIA triad is the foundational security framework: every system design decision that touches security maps to one or more of its three properties.

Confidentiality means preventing unauthorized access to data. In system design: HTTPS for data in transit, AES encryption for data at rest, IAM roles with least privilege, secrets management (Vault, AWS Secrets Manager), and network segmentation via VPCs.

Integrity means preventing unauthorized modification of data. In system design: HMACs on API payloads, digital signatures on critical records, input validation and parameterized queries to prevent injection, immutable audit logs, and database row-level checksums.

Availability means ensuring services are accessible when needed. In system design: load balancing, auto-scaling, multi-region redundancy, DDoS protection (rate limiting, traffic scrubbing), and tested failover/DR procedures.

Important trade-off: these properties can conflict. Maximizing availability (e.g., removing authentication for speed) can compromise confidentiality. Good system design explicitly documents where trade-offs are made and why.

Microservices introduce a large internal attack surface that monoliths avoid. Key threats:

Unauthorized inter-service calls: in a flat internal network, a compromised service can call any other service. Mitigate with mTLS (mutual TLS) or short-lived identity tokens so each service authenticates every incoming call — this is the core of zero-trust networking.

Sensitive data leakage over internal APIs: internal APIs are not automatically safe. Encrypt all internal traffic with TLS and apply schema validation at the API gateway layer.

No centralized audit logging: distributed logs make it nearly impossible to reconstruct an attack timeline. Use a centralized log aggregation platform (ELK, Splunk, Datadog) with tamper-evident storage.

API gateway spoofing: if services blindly trust headers set by a gateway, a compromised internal caller can forge them. Verify JWT signatures at each service, not just at the gateway.

Lateral movement: implement network policies (Kubernetes NetworkPolicy, security groups) so services can only communicate with the specific peers they need. Pair with a service mesh (Istio, Linkerd) for fine-grained traffic control and policy enforcement.

DDoS attacks flood your system with traffic to exhaust bandwidth, compute, or connection capacity. Defense is layered:

Edge-level mitigation: put a CDN or DDoS scrubbing service (Cloudflare, AWS Shield Advanced, Akamai Kona) in front of your origin. These services have massive network capacity to absorb volumetric attacks and can distinguish legitimate traffic from attack traffic using behavioral analysis.

Rate limiting: enforce per-IP and per-user request limits at the API gateway or WAF layer. Combined with CAPTCHAs for interactive endpoints, this raises the cost for attackers significantly.

Auto-scaling: horizontally scale your infrastructure (Kubernetes HPA, AWS Auto Scaling) so sudden traffic spikes do not immediately exhaust capacity while scrubbing kicks in.

Global load balancers: distribute traffic geographically so regional attacks are absorbed without impacting other regions.

Detection: monitor request volume, latency percentiles, and failed authentication rates in real time. Anomaly spikes are the earliest signal of an in-progress attack. Automate runbooks to activate additional protections when thresholds are crossed.

TLS (Transport Layer Security) provides three guarantees for data in transit: confidentiality (the payload is encrypted and unreadable to eavesdroppers), integrity (MAC ensures tampering is detected), and authentication (the server presents a certificate proving its identity).

At scale, certificate management becomes operationally complex. Best practices: use automated certificate rotation via Let's Encrypt with Certbot or ACME protocol integrations — never let certificates expire silently. Offload TLS termination at the load balancer or API gateway (e.g., AWS ALB, Nginx, Envoy) rather than at every application instance, reducing per-service complexity. Enforce HSTS (HTTP Strict Transport Security) so browsers never downgrade to HTTP. Disable deprecated protocol versions (TLS 1.0 and 1.1) and weak cipher suites — enforce TLS 1.2 minimum, preferably TLS 1.3. For internal service-to-service communication, use a service mesh (Istio) that automatically provisions and rotates mTLS certificates via a built-in CA.

Secure cloud data storage requires multiple complementary controls:

Encryption at rest: use cloud KMS-managed keys (AWS KMS, GCP KMS, Azure Key Vault) for all storage services — object stores, databases, and block volumes. Customer-managed keys (CMKs) give you control over key rotation and revocation.

Role-based access control (RBAC): follow the principle of least privilege — each service, function, or user should be granted only the permissions strictly required for its job. Database read replicas used for reporting should not have write access.

Secrets management: never hardcode credentials. Store API keys, database passwords, and certificates in a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault) with automatic rotation enabled.

Audit logging: enable CloudTrail (AWS), Cloud Audit Logs (GCP), or equivalent so you have an immutable record of who accessed what and when. Alert on anomalous access patterns — unexpected geographic locations, unusually large data exports, or access outside business hours.

Data classification: classify data by sensitivity and apply stricter controls (additional encryption layers, narrower access) to PII, financial data, and secrets.

Threat modeling is a structured process for identifying security risks early. It answers four questions: What are you protecting (assets)? Who might attack it (threat actors)? Where are you vulnerable (attack vectors)? How do you defend (mitigations)?

Integration into the SDLC: conduct threat modeling during the design phase, before implementation begins — changes are cheap at design time and expensive in production. For each major feature or architectural change, assemble the relevant engineers and walk through the system diagram using a framework like STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) or DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) to score risks.

Document the findings: list every threat, the component it affects, its likelihood and impact, and the chosen mitigation. Revisit the threat model with every significant feature addition or architecture change. Threat modeling is not a one-time exercise — it is an ongoing practice that matures as the system evolves.

JWT (JSON Web Token) is popular for distributed systems because it is self-contained: a JWT carries all necessary claims — user identity, roles, permissions, and expiration — encoded directly in the token. A receiving service can validate the token by verifying its cryptographic signature (HMAC-SHA256 or RSA) without querying a central session store. This stateless validation is critical for horizontal scalability: any instance of any service can independently validate any token.

Additional advantages: JWTs are compact and URL-safe (transmitted as a Bearer header), they follow a well-known standard (RFC 7519) supported across languages and platforms, and the payload can carry custom claims to avoid extra database lookups in authorization logic.

Key caveats: JWT tokens cannot easily be revoked before expiry without maintaining a token blacklist (which reintroduces statefulness). Store tokens in HttpOnly cookies, not localStorage, to prevent XSS theft. Use short expiration (~15 minutes) with refresh tokens to limit the damage window if a token is stolen. Always validate the signature, iss, aud, and exp claims — never accept tokens with alg: none.

OAuth 2.0 is an authorization framework. It allows a third-party application to obtain limited access to a user's resources on another service — without exposing the user's credentials. The classic example: granting a third-party app permission to post on your Twitter account. OAuth 2.0 issues an access token scoped to specific resources and actions. It says nothing about who the user actually is.

OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0. It adds the concept of an ID token (a JWT) that contains verified identity claims about the user — name, email, subject identifier. OIDC standardizes login flows so that a relying party (your app) can verify the user's identity through an identity provider (Google, Okta, Auth0).

In practice: use OAuth 2.0 when you need delegated resource access; use OIDC when you need to authenticate who the user is. Most modern systems use both: OIDC authenticates the user and OAuth 2.0 scopes control what the issued tokens can access.

RBAC (Role-Based Access Control) grants access based on user roles (Admin, Editor, Viewer). A user is assigned one or more roles, and each role maps to a set of permissions. RBAC is simple to implement and audit, but can lead to "role explosion" as the number of distinct permission combinations grows.

ABAC (Attribute-Based Access Control) grants access based on a combination of attributes: user attributes (department, clearance level), resource attributes (classification, owner), and environmental attributes (time of day, IP address, device trust level). Example policy: "A user with department=HR can access payroll records during business hours from a managed device." ABAC policies are expressed in policy engines like OPA (Open Policy Agent) or AWS Cedar.

For a highly dynamic environment — multi-tenant SaaS, cloud platforms, systems with context-sensitive rules — ABAC is more suitable. It handles fine-grained and context-aware decisions that RBAC cannot express without an impractical number of roles. The trade-off is complexity: ABAC policies are harder to reason about and audit than simple role assignments.

Single Sign-On (SSO) allows a user to authenticate once with a central identity provider and then access multiple applications or services without re-entering credentials. Common protocols: SAML 2.0, OAuth 2.0 / OIDC.

Advantages: Improved user experience — one login for all connected systems reduces friction and credential fatigue. Stronger security posture — centralizing authentication allows the organization to enforce consistent security policies (MFA, password complexity, session timeouts) across all applications from a single control plane. Reduced attack surface — fewer passwords means fewer credentials to phish or breach. Simplified compliance and auditing — central authentication logs provide a unified access trail for SOC 2, HIPAA, and other compliance frameworks. Reduced helpdesk load — fewer forgotten-password tickets when users only manage one set of credentials.

SSO also enables federated identity across organizational boundaries (e.g., B2B partnerships), allowing employees of one company to access a partner's systems using their home-company credentials.

Token-based authentication (particularly JWTs) is powerful but carries specific risks that must be actively mitigated:

Token theft: tokens stored in localStorage are accessible to JavaScript and can be stolen via XSS attacks. Store tokens in HttpOnly, Secure cookies which JavaScript cannot read.

Lack of revocation: a JWT is valid until its exp claim expires — there is no built-in way to invalidate a specific token mid-life. If a user logs out or their account is compromised, the token remains valid. Solutions: maintain a server-side token blacklist (reintroduces statefulness) or use very short expiration windows with refresh token rotation.

Token replay attacks: if a token is intercepted (e.g., MITM on HTTP), an attacker can reuse it. Enforce HTTPS everywhere to prevent interception. Bind tokens to a specific audience (aud claim) and origin where possible.

Algorithm confusion attacks: servers that accept both RS256 and HS256 can be tricked by an attacker who re-signs a tampered token using HS256 with the public key as the HMAC secret. Always specify the expected algorithm server-side — never trust the algorithm from the token header.

Long-lived tokens: tokens with multi-day or no expiry dramatically extend the blast radius of a breach. Use short-lived access tokens (~15 min) and rotate refresh tokens on each use.

A firewall is a network security control that monitors and filters traffic based on predetermined rules at the network or transport layer. It makes allow/deny decisions based on IP addresses, ports, and protocols. Firewalls can be hardware appliances, software (iptables, Windows Firewall), or cloud-native (AWS Security Groups, GCP VPC Firewall Rules). Advanced next-generation firewalls (NGFW) operate at the application layer and can perform deep packet inspection.

A reverse proxy sits between external clients and backend servers, forwarding requests to the appropriate backend and returning responses to the client. The client never communicates directly with the backend server — the reverse proxy hides their identity and addresses. In addition to routing, reverse proxies provide: TLS termination, load balancing, caching, compression, rate limiting, and protection from DDoS by masking origin infrastructure. Examples: Nginx, HAProxy, Envoy, AWS ALB, Cloudflare.

Key distinction: a firewall enforces network access rules and blocks unwanted traffic at the connection level; a reverse proxy operates at the application level and provides both routing and additional security features. In production, they are complementary — firewalls protect the network perimeter and internal segmentation, while reverse proxies add application-layer controls.

Rate limiting controls the volume of incoming requests to a service within a time window. It protects backend services from several classes of abuse:

DDoS and volumetric attacks: by capping the request rate per IP or per client, rate limiting prevents a single source from exhausting server resources. Combined with traffic scrubbing at the CDN layer, it provides layered defense.

API abuse: without rate limits, a malicious or misconfigured client can send thousands of requests per second, starving legitimate users. Rate limiting enforces fair use and SLA compliance.

Credential stuffing and brute force: rate limiting login endpoints to a few attempts per minute makes automated password-guessing attacks economically infeasible.

Common algorithms: Fixed Window — simple counter per time window, but vulnerable to burst at window boundaries. Sliding Window — smooths out boundary bursts. Token Bucket — allows controlled bursting up to a bucket capacity, ideal for APIs with bursty legitimate traffic. Leaky Bucket — enforces a strictly constant output rate regardless of input burst.

Rate limits should be applied at multiple layers: CDN/edge for volumetric protection, API gateway for per-route quotas, and application code for business-logic-specific limits (e.g., per-user transaction frequency).

Zero Trust is a security model built on the principle of "Never Trust, Always Verify." Traditional perimeter-based security assumed everything inside the corporate network was trustworthy — once past the firewall, lateral movement was easy. Zero Trust eliminates this assumption: no user, device, or service is trusted by default, regardless of whether the request originates inside or outside the network.

Core principles: Verify every access request explicitly — authenticate and authorize using all available signals (identity, device health, location, service). Least privilege access — grant the minimum permissions required for the task, for the shortest necessary duration. Micro-segmentation — divide the network into small zones so that a compromised service cannot freely access other services. Continuous monitoring — log and analyze all traffic; flag behavioral anomalies in real time.

Importance for modern architectures: cloud workloads, remote workers, and microservices have dissolved the traditional perimeter entirely. Zero Trust is the only model that works when your "network" spans multiple clouds, on-premises data centers, and employee home networks. It also limits blast radius — even if one service or credential is compromised, tight segmentation and least-privilege policies prevent the attacker from moving laterally.

Kubernetes security is multi-layered — no single control is sufficient:

Container image security: use minimal, trusted base images (Alpine Linux, distroless). Scan images for CVEs before deployment using tools like Trivy or Clair. Sign images with Cosign to ensure only approved images are deployed.

RBAC: define fine-grained Kubernetes Role and ClusterRole objects. Service accounts should have the minimum permissions needed — avoid cluster-admin for application workloads. Audit RBAC policies regularly.

Pod Security Admission (PSA): enforce security profiles that prevent containers from running as root, disallow privilege escalation, restrict host path mounts, and enforce read-only root filesystems where possible.

Network Policies: by default, Kubernetes allows all pods to communicate with all other pods. Implement explicit NetworkPolicy resources to whitelist only the required pod-to-pod communication paths, blocking lateral movement.

Service mesh for mTLS: deploy Istio or Linkerd to automatically provision and rotate mTLS certificates for all service-to-service communication, with traffic policy enforcement at the sidecar proxy level.

Secrets management: never store secrets in plaintext in Kubernetes manifests or ConfigMaps. Use Kubernetes Secrets (encrypted at rest via KMS) or external solutions like HashiCorp Vault with the Vault Agent Injector or External Secrets Operator to pull secrets at runtime.

The OWASP Top 10 (2021) represents the most critical web application security risks:

Injection (SQL, NoSQL, OS command): attackers send malicious input that gets executed as code. Mitigate with parameterized queries, prepared statements, and WAF rules — never concatenate user input into queries.

Broken Authentication: weak passwords, missing MFA, credential stuffing. Mitigate with strong password policies, MFA, rate-limited login endpoints, and secure password hashing (bcrypt, Argon2).

Sensitive Data Exposure: unencrypted PII in transit or at rest. Mitigate with HTTPS/TLS everywhere, encryption at rest (AES-256), and data minimization.

XML External Entities (XXE): malicious XML input that reads files or SSRFs. Mitigate by disabling external entity processing in XML parsers and validating all XML input.

Broken Access Control: users accessing resources beyond their authorization. Mitigate with server-side authorization checks on every request, RBAC, and deny-by-default access policies.

Security Misconfiguration: default credentials, open cloud storage, verbose error messages. Mitigate with hardened baseline configurations, automated config auditing (CIS Benchmarks), and removing all unnecessary features and services.

Cross-Site Scripting (XSS): injected scripts run in victim's browser. Mitigate with output encoding, Content Security Policy (CSP) headers, and input sanitization.

Insecure Deserialization: untrusted data deserialized into objects, enabling RCE. Mitigate by avoiding deserialization of untrusted data, using signed/encrypted serialization formats.

Using Components with Known Vulnerabilities: outdated libraries with CVEs. Mitigate with automated dependency scanning (Snyk, Dependabot) and a patching process with SLA.

Insufficient Logging & Monitoring: attackers operate undetected for months. Mitigate with centralized, tamper-evident logging, real-time alerting on anomalies, and regular incident response drills.

A service mesh is a dedicated infrastructure layer — typically implemented via sidecar proxies (Envoy in Istio, Linkerd proxy) — that intercepts all service-to-service communication and applies policies transparently, without requiring application code changes.

Mutual TLS (mTLS): the mesh's built-in CA automatically provisions short-lived certificates for each service identity. Every connection between services is mutually authenticated and encrypted, eliminating the "trust the internal network" assumption. Certificate rotation is automated.

Access control policies: the mesh enforces which services are allowed to communicate with which other services. A service-to-service policy can be as specific as "Service A can call Service B's /payment endpoint using POST — nothing else."

Traffic observability: the sidecar proxies emit detailed telemetry — request rates, error rates, latency histograms — and full distributed traces. This makes anomalous communication patterns (unexpected service-to-service calls, spike in error rates) immediately visible.

Rate limiting and circuit breaking: the mesh can apply these resilience patterns at the infrastructure layer, protecting services from being overwhelmed without application-level code. Popular service meshes: Istio, Linkerd, Consul Connect, AWS App Mesh.

IAM (Identity and Access Management) is the control plane for cloud security — it governs who or what can access which cloud resources and what actions they can perform.

Key functions: Authentication — verifying the identity of users, applications, or services (via passwords, API keys, service account tokens, or federated SSO). Authorization — determining what an authenticated principal is permitted to do, expressed as IAM policies that attach to users, groups, roles, or resources. Least privilege enforcement — IAM policies allow fine-grained permission scoping: a Lambda function that reads from one S3 bucket should be granted exactly s3:GetObject on that specific bucket ARN, nothing broader. Audit logging — all IAM-governed API calls are logged (AWS CloudTrail, GCP Cloud Audit Logs) for compliance and incident investigation.

IAM also enables temporary credentials via role assumption (AWS STS AssumeRole) — workloads receive short-lived credentials that automatically expire, dramatically reducing the risk of long-lived credential leakage. In Kubernetes, IAM Roles for Service Accounts (IRSA) or Workload Identity (GCP) bind pod-level service accounts to cloud IAM roles, enabling fine-grained cloud API permissions without mounting static credentials into pods.