Security Cheat Sheet

How to Use This Sheet

Security work fails when it becomes a checklist detached from real systems.

Use this sheet as a field reference for design reviews, implementation checks, production troubleshooting, security triage, and audit preparation.

Rule: prove the control with evidence. A policy statement is not enough if the system behavior says otherwise.

---

OWASP Top 10: 2025

Use the OWASP Top 10 as an awareness and review map, not as the full security program.

Review pattern:

1. Identify the asset and trust boundary.
2. Identify who can act on it.
3. Prove authorization on the server side.
4. Validate input at the boundary.
5. Confirm secrets, keys, logs, and errors are handled safely.
6. Confirm monitoring can detect abuse.

---

Security Design Baseline

Design review prompt:

Actor -> action -> object -> decision point -> evidence -> alert -> recovery

If one part is missing, the control is incomplete.

---

Authentication

Authentication proves who the user or service is.

Do not:

• silently truncate passwords
• store passwords with SHA-256, MD5, or reversible encryption
• expose whether an email or username exists during login or recovery
• let internal admin or service accounts log in through public user flows

Useful implementation checks:

# TLS-protected login page
curl -I https://example.com/login

# Look for cookie flags after login
curl -vk -I https://example.com/

# Check rate-limit behavior with controlled test accounts only
for i in 1 2 3 4 5; do curl -s -o /dev/null -w "%{http_code}\n" https://example.com/login; done

---

Password Storage

Passwords need slow, adaptive hashing. Plain hashes are not enough.

Password storage rules:

• unique salt per password
• adaptive work factor
• constant-time comparison
• no reversible encryption for passwords
• no plain SHA-256, SHA-1, MD5, or fast hashes
• planned migration for legacy hashes

Evidence to ask for:

algorithm, work factor, salt behavior, pepper storage, migration plan,
hash verification function, test evidence, and breach response procedure

---

Authorization and Access Control

Most serious application bugs are authorization bugs.

Server-side authorization check:

subject = authenticated actor
action = requested operation
object = exact resource
context = tenant, ownership, role, risk
decision = allow or deny
evidence = log entry

Tests to include:

• user A cannot read or modify user B object
• tenant A cannot enumerate tenant B data
• read role cannot call write endpoint
• disabled user cannot use old session
• admin downgrade revokes privileged access

---

Session, Token, and Cookie Controls

Cookie baseline:

Session controls:

• rotate session ID after login and privilege elevation
• expire idle and absolute sessions
• revoke sessions after password or MFA change
• store tokens securely on the server or in hardened browser storage
• avoid long-lived bearer tokens in local storage
• bind high-risk changes to reauthentication

JWT checks:

# Decode header and payload only; this does not verify signature
cut -d. -f1 token.jwt | base64 -d
cut -d. -f2 token.jwt | base64 -d

JWT review:

---

Input Validation and Injection Defense

Input validation reduces attack surface. Output encoding prevents execution in the wrong context.

Danger signs:

string-concatenated SQL
shell=True
eval()
innerHTML with untrusted data
unsafe deserialization
unvalidated redirect URL
wildcard CORS

Command review examples:

rg -n "eval\\(|innerHTML|shell=True|exec\\(|SELECT .*\\+" .
rg -n "Access-Control-Allow-Origin: \\*" .
rg -n "redirect|returnUrl|next=" .

---

API Security

API security starts with object and function authorization.

HTTP checks:

curl -i https://api.example.com/v1/me
curl -i -H "Authorization: Bearer <token>" https://api.example.com/v1/users/123
curl -i -X POST -H "Content-Type: application/json" -d '{"role":"admin"}' https://api.example.com/v1/profile

Abuse cases to test:

• change object ID
• change tenant ID
• add unexpected JSON fields
• replay an old request
• use read token on write endpoint
• remove token and check denial

---

Browser and HTTP Security Headers

Headers do not replace secure design, but they reduce browser-side risk.

Checks:

curl -I https://example.com/
curl -sI https://example.com/ | grep -iE 'strict|content-security|x-content|referrer|permissions|cross-origin'

CSP rollout pattern:

1. start with Content-Security-Policy-Report-Only
2. collect violations
3. remove unsafe inline dependencies
4. enforce a narrow policy
5. monitor reports after deployment

Avoid relying on X-XSS-Protection; modern defense is CSP plus output encoding.

---

CORS and Cross-Site Request Forgery

CORS controls browser reads across origins. It is not an authentication or network firewall.

CSRF controls:

• SameSite cookies
• CSRF token for state-changing requests
• origin and referer validation
• reauthentication for sensitive actions
• no state change through GET

Checks:

curl -i -H "Origin: https://evil.example" https://api.example.com/account
curl -i -X POST -H "Origin: https://evil.example" https://example.com/profile

---

TLS and Certificate Checks

TLS protects data in transit, but only if certificate, protocol, and hostname behavior are correct.

Inspect remote TLS:

openssl s_client -connect example.com:443 -servername example.com
openssl s_client -connect example.com:443 -servername example.com -showcerts
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Check versions:

openssl s_client -tls1_2 -connect example.com:443 -servername example.com
openssl s_client -tls1_3 -connect example.com:443 -servername example.com
nmap --script ssl-enum-ciphers -p 443 example.com

Certificate review:

Local certificate:

openssl x509 -in cert.pem -noout -text
openssl x509 -in cert.pem -noout -subject -issuer -dates -ext subjectAltName
openssl pkey -in key.pem -check

---

Cryptography and Data Protection

Use established libraries and managed key services. Do not design custom cryptography.

Avoid:

• MD5 and SHA-1 for security
• ECB mode
• hardcoded keys
• nonce reuse
• homegrown encryption format
• storing encryption keys beside encrypted data

Hashing vs encryption:

---

Secrets Management

Secrets include passwords, API keys, tokens, private keys, database URLs, webhook secrets, signing keys, and cloud credentials.

Baseline:

Repo checks:

rg -n "AKIA|BEGIN PRIVATE KEY|password=|SECRET|TOKEN|DATABASE_URL" .
git log -p --all | rg -n "SECRET|TOKEN|PRIVATE KEY|password="

If a secret is committed:

1. revoke it
2. rotate dependent systems
3. remove from history if needed
4. check logs for use
5. add detection to CI

Deleting the line is not enough.

---

Cloud and Infrastructure Security

Cloud controls are split across identity, network, storage, logging, and workload configuration.

AWS examples:

aws sts get-caller-identity
aws iam get-account-summary
aws s3api get-public-access-block --account-id <account-id>
aws cloudtrail describe-trails

Kubernetes examples:

kubectl get pods -A -o wide
kubectl auth can-i --list
kubectl get networkpolicies -A
kubectl get secrets -A
kubectl describe pod <pod> -n <namespace>

Red flags:

• wildcard admin policies
• public buckets
• security groups open to 0.0.0.0/0 for admin ports
• plaintext secrets in environment variables without governance
• no audit logs
• no tested restore

---

Host and Endpoint Security

Host security is useful only when it is observable and repeatable.

Linux checks:

ss -lntup
systemctl list-units --type=service --state=running
systemctl list-timers --all
last -a | head -50
journalctl -p warning..alert --since "24 hours ago"
find / -perm -4000 -type f 2>/dev/null

Patch state:

apt list --upgradable
dnf updateinfo list security
rpm -qa --last | head
grep " install " /var/log/dpkg.log

Endpoint control evidence:

---

Vulnerability and Dependency Management

A vulnerability process needs scope, severity, ownership, due dates, and exception control.

Commands:

nmap -sV -O 203.0.113.10
trivy image example/app:latest
trivy fs .
npm audit
pip-audit
osv-scanner .

Do not treat scanner severity as the final decision. Exposure, exploitability, asset criticality, and compensating controls matter.

---

Logging, Monitoring, and Alerting

Logs must support investigation without leaking secrets.

Security event baseline:

Do not log:

• passwords
• session cookies
• bearer tokens
• private keys
• full payment card numbers
• unnecessary personal data

Useful checks:

journalctl --since "1 hour ago"
grep -Rni "password\\|token\\|secret\\|authorization" /var/log 2>/dev/null
curl -sS https://example.com/does-not-exist

---

Incident Response Quick Chain

Incident work is about preserving truth while reducing harm.

1. Declare severity and owner.
2. Preserve volatile evidence.
3. Establish timeline.
4. Contain without destroying evidence.
5. Eradicate root cause.
6. Recover service safely.
7. Notify required stakeholders.
8. Capture lessons and control fixes.

Initial evidence:

date -Is
hostnamectl
who
w
ss -lntup
ps aux
last -a | head -50
journalctl --since "24 hours ago" > journal-last-24h.log

Containment options:

Do not start with rm, reboot, or blanket firewall flushes unless the risk demands it and the decision is recorded.

---

Security Review Checklist

Use this before release or major change.

Release question:

If this control fails at 2 AM, what evidence proves what happened and who can fix it?

---

Quick Command Map

---

Keep Current

Security guidance changes. Refresh this sheet against primary sources when making policy decisions:

• OWASP Top 10
• OWASP Cheat Sheet Series
• OWASP ASVS
• MDN HTTP Observatory
• NIST Digital Identity Guidelines

The goal is not to memorize every control.

The goal is to know what to verify, what evidence proves it, and what failure path to prepare before production.