IDOR Check — Can Users Reach Each Other's Records by Changing an Id?
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee.
What the issue is
An endpoint that looks up records by an id from the request, without checking the record belongs to the signed-in user, lets any account read or change other users' data by editing the id in the URL.
Why AI tools generate it
AI-generated routes usually include the login check but not the ownership check — the demo works, the gap is invisible, and the endpoint ships trusting the client to send honest ids.
How DevMeth detects it
A code scan finds handlers that query by a request-supplied id while your own schema and other queries treat the data as user-owned, then flags the ones with no ownership predicate on the query.
Your API lets any signed-in user read or change other people's records
WHAT WE FOUND
C31 — masked sample
The fix, in three steps
Scope every by-id query to the signed-in user (add their id to the where clause), return 404 for foreign records, and never trust the client-supplied id alone. Three steps.
Run a free scan and each finding carries a paste-ready fix prompt you can act on.
Try a free scanFAQ
Doesn't the login check already stop this?
No — logging in proves who the caller is, not what they may access. Without an ownership predicate on the query, any signed-in user can pass anyone else's id.
How is this different from a missing auth check?
A missing auth check lets anonymous users in. This lets any signed-in user reach other users' records — same data exposure, harder to spot in testing because you were logged in.
What's the fix?
Add the caller's user id to every by-id query's filter, and return 404 (not 403) when the record isn't theirs so ids can't be enumerated.
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee. A clear result means each known pattern was checked and found clear or not applicable for your app; it is not a guarantee of security.