Skip to content

Security Theatre

Application security: authentication, tokens and secure headers

t/security-theatre

Auth, tokens, headers, and the password rule that makes things worse. Practical security for people shipping products.

10 members
8 posts
Created Aug 2026

Community rules

3 rules for t/security-theatre

  1. No live vulnerabilities

    Disclose privately first. Do not post a working exploit against something still running.

  2. Bring the detail

    Versions, error text, what you already tried. "It does not work" is not a question anyone can answer.

  3. No drive-by self promotion

    Share your own work when it answers the thread. A link with no context is a advert, and it gets removed.

Top contributors

  1. Fatima Al-Sayed#1 · 77 rep · 5 posts
  2. Nadia Benali#2 · 60 rep · 2 posts
  3. Hannah Weiss#3 · 9 rep · 1 post
  4. Tomasz Kowalski#4 · 4 rep
  5. Chloe Barnes#5 · 2 rep

Discussions

1

  • Security Theatre

    The main discussion

    Primary

    Nobody has said anything yet. Be the first.

LatestTopUnanswered

Showing 8 posts.

Posts in t/security-theatre

Fatima Al-Sayed141
t/security-theatre2 min

A pentester found an IDOR in our statements API in 10 minutes. The fix was boring

Last quarter an external pentest found that any logged-in customer could download any other customer's account statement. It took the tester around 10 minutes. I want to share it because the bug was very ordinary, and ordinary bugs are the ones that survive reviews. The endpoint was GET /api/statements/{id} . It checked that the request had a valid session. It did not check that the statement belonged to the…

3

Nadia Benali614
t/security-theatre

forcing users to change their password every 90 days does not make you secure, it makes everyone go from Summer2024! to Summer2024!! and write it on a sticky note. NIST dropped this advice in 2017. your IT policy is doing security cosplay, not security

5

  • Wolfgang Engel
    This is correct and I will add one thing: forcing rotation while still storing the previous passwords to prevent reuse means you are now keeping a history of your users credentials. People rarely think about what that comparison requires.
Hannah Weiss132
t/security-theatre3 min

Pseudonymisation is not anonymisation: a note for people building health apps in the EU

I review data flows for health projects quite often, and one sentence appears in almost every design document: "the data are anonymised". Then I look closer and the data are pseudonymised. The difference is not academic. Under the GDPR it decides whether the law applies at all. The two words Pseudonymised data are personal data where the direct identifiers (name, insurance number) were replaced with something else,…

3

Fatima Al-Sayed159
t/security-theatre3 min

OAuth in mobile apps: use PKCE, and stop shipping client secrets in the APK

Every few months I review a mobile app that ships an OAuth client secret inside the binary. Extracting a string from an APK or IPA takes about ten minutes, so that secret is public the day the app is published. Here is the setup that actually works for native apps. Mobile apps are public clients A public client is one that cannot keep a secret: native apps, single page apps, desktop apps. The OAuth specs say so…

3

Fatima Al-Sayed547
t/security-theatre3 min

Where should a browser app keep its tokens? Not localStorage (mostly)

This question comes up in every code review I do for a new web app, so I am writing the long answer once. The short version For a first-party web app (your frontend talks to your own API): keep the session in an HttpOnly, Secure, SameSite cookie , and do not put long-lived tokens anywhere JavaScript can read them. If you must use OAuth access tokens in the browser, keep the access token in memory and short-lived,…

8

  • Chloe Barnes
    I have tokens in localStorage on my app. I feel personally attacked. bookmarking to fix this weekend (I will not fix this weekend)
    1 reply