Skip to content

The ideas every other security note builds on. Specifics are in 2. Web Application Security, 3. HTTP Security Headers and CSP, 4. Cloud Security and 5. Secure Coding and Supply Chain.

Principles at a glance

Principle Meaning Example
CIA triad Keep data confidential, keep it intact, keep it available Encrypt (C), checksum / sign (I), backups and redundancy (A)
Least privilege Give only the access a job needs, for as long as it needs it A deploy role that can write one bucket, not *
Defence in depth Layer controls so one failure is not a breach WAF + input validation + parameterised queries + DB user with limited rights
Secure by default The safe setting is the default one New buckets private, new users have no access
Fail closed On error, deny Auth service down means "no", not "yes"
Zero trust Never trust by network location; verify every request Identity-aware access instead of "inside the VPN"
Separation of duties No single person can do and approve Author cannot merge to production alone
Minimise attack surface Remove what you do not need Close unused ports, delete unused accounts, drop unused dependencies

AAA: Who, What, Prove It

Step Question Examples
Authentication Who are you? Password + MFA, passkeys, certificates, OIDC
Authorisation What may you do? RBAC, ABAC, policies, scopes
Accounting / audit What did you do? Audit logs, CloudTrail, activity logs
  • MFA everywhere that matters (admin, cloud console, email, source control). Prefer passkeys or authenticator apps over SMS
  • Store passwords only as slow salted hashes (Argon2id, bcrypt, scrypt, PBKDF2), never encrypted or plain
  • Authentication proves identity; check authorisation on every request on the server, not in the UI

Threat Modelling

Ask four questions: What are we building? What can go wrong? What do we do about it? Did we do a good job?

STRIDE is a checklist for "what can go wrong":

Letter Threat Property broken Typical control
S Spoofing Authentication MFA, signed tokens
T Tampering Integrity Signatures, TLS, checksums
R Repudiation Non-repudiation Audit logs
I Information disclosure Confidentiality Encryption, access control
D Denial of service Availability Rate limits, autoscaling, CDN
E Elevation of privilege Authorisation Least privilege, input validation

Draw a data-flow diagram, mark trust boundaries (browser to server, server to database, your cloud to a third party) and look at what crosses each one.

flowchart LR
    U[User browser] -- HTTPS --> W[WAF / CDN]
    W --> A[App server]
    A -- private network --> D[(Database)]
    A -- API key --> X[Third-party API]
    subgraph Trust boundary: internet
    U
    end
    subgraph Trust boundary: your cloud
    W
    A
    D
    end

Cryptography in Practice

Need Use Avoid
Data in transit TLS 1.2+ (prefer 1.3), valid certificates Plain HTTP, self-signed in production
Data at rest Disk / database / object encryption with managed keys (AES-256) Home-made schemes
Passwords Argon2id, bcrypt MD5, SHA-1, plain SHA-256
Integrity / signing HMAC, digital signatures (Ed25519, RSA-PSS) Unkeyed hashes for trust
Random tokens OS CSPRNG (secrets in Python) random, timestamps
Key storage A KMS / vault / HSM Keys in source code or images

Rule: do not invent cryptography. Use a well-reviewed library and keep keys apart from the data they protect.

Vulnerability Management

flowchart LR
    I[Inventory assets] --> S[Scan and find]
    S --> P[Prioritise by risk]
    P --> F[Fix or mitigate]
    F --> V[Verify]
    V --> I
  • CVE identifies a known flaw; CVSS scores severity (0 to 10). Prioritise by severity and exposure (internet-facing, exploitable, sensitive data)
  • Patch on a schedule; track end-of-life software
  • Where to follow new CVEs, exploits and news (NVD, CISA KEV, EPSS, OSV, advisories, research blogs): 8. Staying Current
  • Pen tests and bug bounties find what scanners miss. Always have written permission before testing anything you do not own
  • Passive checks are safe to run often: see Siteward Web Security Scanner

Incident Response (the short version)

  1. Prepare: contacts, runbooks, logging in place, backups tested
  2. Detect: alerts, user reports, anomaly detection
  3. Contain: isolate the host, revoke keys and sessions
  4. Eradicate and recover: remove the cause, restore from known-good
  5. Learn: blameless review, fix the root cause, update detection

Good logs decide how fast you can answer "what happened, when, from where". See 4. Cloud Security for audit logging services.

Everyday Checklist