IDOR (Insecure Direct Object Reference)

An access-control flaw where changing an ID in a request lets a user read or edit records that belong to someone else.

IDOR happens when your app uses a user-supplied identifier (like /invoice/1043) to fetch data without checking that the requester is allowed to see it. Change the number to 1044 and you get someone else's invoice. The bug is one missing ownership check, not anything exotic.

For a solo founder, this is one of the most common ways early products leak customer data. It rarely shows up in normal testing because you only ever look at your own account. It also tends to multiply: every endpoint that takes an ID is a potential leak.

The fix is to scope every query to the authenticated user and verify ownership server-side on each request. If you want to know whether yours is exposed before launch, IDOR explained walks through real cases, and Kalit Pentest probes your endpoints for it automatically.

Related terms

SSRF (Server-Side Request Forgery)A flaw where an attacker tricks your server into making requests to internal systems or cloud metadata it should never reach.SQL injection (SQLi)A flaw where untrusted input is mixed into a database query, letting an attacker read, change, or destroy your data.XSS (Cross-Site Scripting)A flaw where attacker-controlled script runs in another user's browser, letting it steal sessions or act as that user.CSRF (Cross-Site Request Forgery)An attack that tricks a logged-in user's browser into sending an unwanted state-changing request to your app.