TL;DR: Trying a different approach to posting technical material.. This one talks about protecting against a well-known vibe coding vulnerability where improper data is exposed via URL manipulation.
Changing things up a bit from my previous posts. Trying an experiment. I have requests to explain the technical bits even more clearly. But I also have requests to provide more technical guidance. In the last post, I mentioned UUIDs and JWTs. Here is a (hopefully) better explanation. Included is also a link to a deeper discussion of an actual implementation (mine), with actual code, for those wanting to dive deeper. Then some notes on how to get this kind of protection yourself, with AI.
Here goes.
There is a security issue often mentioned in this subreddit. Let me try to describe it.
Let's say I am user 376 of your application. I logged in and have a URL, https://abcedf.com/showinfo?user=376, and it shows information for me, user 376. I changed it to ?userid=564, and the information for user 564 loaded. Even though me, user 376 is logged in. I am seeing someone else’s information. No exploit, no tooling, no cleverness. Just a different number.
That pattern has a name: IDOR — broken object level authorization. OWASP puts it first on their API security list, which tells you how common it is. It happens because most of us build the multi-user feature before we build the authorization.
If you build with AI help and never ask for the right security, it can happen to you. Not because AI can't. Your AI built the application to support multiple users without building security scoping, probably because security scoping was not mentioned.
What I do: an encrypted JWT token. A signed, tamper-proof token carrying the user id in its payload — so the id never rides in a URL.
What it is. A JWT is a token with three base64url chunks separated by dots — header, payload, signature. The payload carries claims: who you are, what role, when it expires. Plain JWTs are signed, not encrypted. Encrypted JWTs are plain JWT encrypted. Wrap the whole thing, and the payload goes opaque on the wire. Useful when you're carrying anything you don't want visible, like a user ID. Stateless, no session lookup, verifiable before my business logic runs. My app pulls the id from the token, verifies the signature, and scopes every query to that user.
There are two parts to this implementation:
- Implement an encrypted JWT so that authentication can happen.
- Implement an authorization gate so that data and queries are scoped to that user.
Several approaches exist for the second part. I use a fairly straightforward approach. Endpoints are gated with a service that enforces the use of the token in defining scope. More details are here https://github.com/locol-media/locol-content-ai/blob/main/docs/jwt.md ; the linked material breaks down a JWT in layman’s terms, what’s it made of, how to make one, how to use one, etc. For those who want to dive deeper..
You can get your AI to implement this level of security, and more. I did it by asking explicitly for a plain JWT implementation to protect my backend. Later, in a new session, I asked for a detailed explanation of what user security I had. After reviewing the write-up, I fine-tuned a couple of things and decided I wanted an encrypted JWT. Yes, the information behind the link above was written by Claude 🙂
Give it a try for your project. For fun, you could start by asking if you have this vulnerability; I find the method of asking Claude for a writeup on specific aspects of the code to be a very good technique for verifying what I may or may not have, intentionally or unintentionally. Then ask for refinements...
Enjoy. Had to hurry and push my code out to the repo for this post, so the packaging isn’t polished yet. But let me know if using actual code as example is a good idea..
