Security basics

Backups contain the same sensitive data as production; protect them with access control, encryption, and integrity checks. Ensure backups are not writable by the same threat that could corrupt production. Use this when designing or auditing backup and restore.

Data in transit is encrypted between client and server (e.g. TLS); data at rest is encrypted on disk or in storage. Both are needed for full protection. Use this when designing or auditing where encryption is required.

Linux file permissions are read, write, execute for owner, group, and others. Use chmod and chown to set them; restrict sensitive files (keys, config) to owner-only read. Use this when fixing permission denied or securing config and keys.

When someone leaves or an account is compromised, revoke all access immediately: disable or delete the account, revoke tokens and keys, remove from groups and roles, and invalidate sessions. Use this during offboarding or incident response.

Store API keys in a secret manager or env; never in code or public config. Use short-lived tokens where the API supports it; scope keys to the minimum permissions; rotate and revoke when leaked or when no longer needed. Use this when adding or hardening API access.

Least privilege means granting only the minimum permissions needed for a task. Apply it to users, services, and roles to limit blast radius when an account is compromised. Use this when designing roles or reviewing who has access to what.

Log auth events, admin actions, and access to sensitive data so you can detect and investigate incidents. Send logs to a central, protected store; retain per policy and alert on high-risk patterns. Use this when designing or improving security visibility.

Set minimum length, complexity, and expiry for passwords where they are still used; prefer MFA and passwordless where possible. Use this when configuring IdP or application password rules so users cannot choose weak or reused passwords.

Choose the right credential type for each use case: passwords for human login, keys for SSH and automation, tokens for APIs and short-lived access. Use this when designing auth for a service or when replacing passwords with stronger methods.

Use this checklist when deploying a new system or reviewing an existing one: strong auth, least privilege, encryption, logging, and no unnecessary exposure. Covers auth, secrets, permissions, network, and backup security in one pass.

Protect SSH private keys with passphrases and correct file permissions; use one key per purpose or environment; rotate and revoke keys when people leave or keys are compromised. Use this when hardening SSH access or responding to a key leak.

HTTP security headers tell browsers how to behave: HSTS, CSP, X-Frame-Options, and others reduce clickjacking, XSS, and protocol downgrade. Use this when hardening a web application or API so you know which headers to set and what they do.

Secrets are credentials (passwords, keys, tokens) that must stay confidential. Store them in a dedicated secret manager or vault, not in code or config files in repo. Use this when adding a new service or moving secrets out of config.

Authentication is verifying identity (who you are) before granting access. Learn the difference between authentication and authorization, and why strong auth (passwords, keys, MFA) is the first line of defense. Use this when designing access or explaining auth to others.

Authorization is deciding what an authenticated identity can do (read, write, delete, admin). Learn role-based and attribute-based models, least privilege, and how to apply authorization after authentication. Use this when designing permissions or debugging access denied.

TLS (Transport Layer Security) encrypts and authenticates traffic between client and server. Use it for all HTTP, APIs, mail, and database connections that carry sensitive data. Use this when enabling HTTPS or securing any network service.

Use MFA wherever a single stolen password or key could cause serious harm: admin accounts, production access, and sensitive data. Learn what counts as a second factor and how to enforce it. Use this when deciding where to require MFA.

Encryption keys must be stored and used securely: separate from the data, access-controlled, and rotated per policy. Use a KMS or vault; avoid storing keys in config or code. Use this when enabling encryption or designing key lifecycle.

Use logs and audit trails to see who accessed what and when. Enable audit logging for auth, admin actions, and data access; centralize and protect logs so they survive and are usable after an incident. Use this when investigating an incident or building auditability.

Review auth logs for failed logins, logins from unexpected IPs or times, and new device or location. Use centralized logs and alerts to detect takeover or abuse. Use this when investigating a reported incident or building detection.

Rotate passwords, API keys, and certificates on a schedule or after a suspected leak without causing outages. Add the new secret first, update consumers, then revoke the old one. Use this when implementing rotation or responding to a compromise.

When a security incident occurs, contain impact, preserve evidence, eradicate the cause, and recover. Have a plan and roles defined in advance; use runbooks for common scenarios. Use this when building or executing an incident response process.

When a security incident is declared, use this checklist: contain impact, preserve evidence, notify, eradicate, recover, and document. Ensures nothing is missed during a high-stress response. Use this in parallel with incident response basics.