Why do AI code assistants introduce authorisation bugs?
In short
- Most vulnerability classes have a local fix a model can learn. Authorisation does not.
- Whether a user may read a row is a business rule, and it is not in the file or the prompt.
- The generated code passes its tests, because the tests are written by whoever signs in as the owner.
Because authorisation is the one property that cannot be judged from the code.
Ask an assistant for a database query and you usually get a parameterised one. Ask for password storage and you usually get a hashing library. Those patterns dominate the training data, and the correct form sits inside the same expression as the bug.
Authorisation is not like that. Whether a signed-in user may read order 8231 depends on
a rule about the product — orders belong to the customer who placed them, except for
support agents, except for shared team accounts. None of that is in the route handler, and
usually it is not written down anywhere.
So a model asked to fetch an order by id writes a function that fetches an order by id. That is a correct implementation of the request and an IDOR at the same time, and nothing in the visible context would have told it otherwise.
Two things keep it hidden after it is written. The code passes its tests, because the happy-path test signs in as the owner. And review reads for correctness rather than authority — a reviewer sees a query, a null check and a response, and nothing looks wrong, because nothing is wrong except an absence.
This is not a new bug class. Assistants have made it cheap to produce plausible handlers faster than anyone reviews them.