Authentication mistakes AI coding tools keep making

Last updated: September 2026

Ask an AI coding assistant to build a login screen and it will give you one in seconds. It will look right. It will have a form, a token, a redirect, and a friendly error message. What it will often be missing is the part that does not show up on screen: the check, on the server, that this user is allowed to do this thing to this record. That check is the whole point of authentication and authorisation, and it is the single most common thing we find missing when we audit AI-built software.

This is part of our software security coverage, and it sits underneath the question a buyer always asks us first: is this safe to ship? For code that decides who can sign in and what they can touch, the honest answer is usually "not until someone has checked the parts the tool skipped".

Authentication and authorisation are not the same thing

The two words get used interchangeably, and the confusion is where a lot of the damage starts. Authentication is proving who you are: the login, the password, the token, the second factor. Authorisation is what you are allowed to do once you are in: whether you can read this invoice, delete that account, or reach an admin route at all.

Most of the severe findings we report are authorisation failures, not authentication ones. OWASP puts Broken Access Control at the top of its 2021 Top 10, noting that 94% of the applications it tested had some form of it, and that the category accounted for 318,487 occurrences, more than any other on the list [1]. MITRE files the underlying weakness as CWE-862, Missing Authorization: the product "does not perform an authorization check when an actor attempts to access a resource or perform an action" [2]. An AI tool is very good at building the front door. It is much less reliable about the locks on every internal door behind it.

Why AI coding tools produce these flaws

Better models have not produced more secure code, and that is the uncomfortable finding across the research. Veracode tested more than 100 large language models across four languages in 2025 and found that "45% of code samples failed security tests and introduced OWASP Top 10 security vulnerabilities", with Java the worst at a "72% security failure rate" [3]. Its conclusion was blunt: security performance "remained flat, regardless of model size or training sophistication" [3]. This is not a defect that the next model will train away. An earlier peer-reviewed study from NYU, "Asleep at the Keyboard", found roughly 40% of the programs GitHub Copilot generated across 89 security-relevant scenarios were vulnerable [4]. Years of progress on writing code that works have barely moved the line on writing code that is safe.

The more worrying result is about the person, not the model. A Stanford study presented at ACM CCS in 2023 found that developers given an AI assistant "wrote significantly less secure code" than those without one, and, critically, "were more likely to believe they wrote secure code" [5]. The tool lowers your guard at the same moment it raises your risk. Snyk's own survey work found a similar gap in perception, with 63.3% of respondents rating the security of AI-generated code highly even as the report warned that such code "consistently injects security risk" [6].

The mechanism is simple once you have seen it a few times. A model reproduces the most common pattern in its training data, and the most common pattern is the happy path: authenticate the user, then get on with the feature. The authorisation check is the unglamorous line that was often not in the example either. When a developer then copies a working endpoint to make a similar one, the ownership check that was correct on the original is the easiest thing to forget on the copy. Secrets follow the same logic: GitGuardian found that commits made with an AI assistant leaked secrets at a 3.2% rate against a 1.5% baseline, roughly double [7].

The authentication mistakes we keep finding

None of the following is exotic. Each is a control an AI tool will happily leave out while producing code that runs perfectly well in a demo.

1. Authorisation enforced in the browser, not on the server. The interface hides the admin button from ordinary users, but the endpoint behind it never checks who is calling. OWASP's guidance is unambiguous: access-control checks "must be performed server-side", because client-side checks "can enhance the user experience but are not to be relied upon for security since this logic can often be bypassed" [8]. The right default is deny-by-default: refuse the request unless something explicitly allows it [8].

2. Object-level checks skipped. An endpoint reads a record ID from the request and returns the record without confirming the logged-in user owns it, so changing /invoice/123 to /invoice/124 shows you someone else's invoice. MITRE calls this CWE-639, Authorization Bypass Through User-Controlled Key, and notes it is "commonly known as Insecure Direct Object Reference (IDOR) or Broken Object Level Authorization (BOLA)" [9]. OWASP lists BOLA as the number-one API risk, and its fix is exactly the checklist item AI tools miss: an authorisation check "in every function that uses an input from the client to access a record" [10].

3. Endpoints with no authentication at all. A background job, an internal API, a route added late in the build: functionality that assumes it is unreachable, and is not. This is CWE-306, Missing Authentication for Critical Function, where the product "does not perform any authentication for functionality that requires a provable user identity" [11], and CWE-287, Improper Authentication, where an identity is claimed but never properly proven [12].

4. JSON Web Tokens accepted without a valid signature. JSON Web Tokens (JWTs) are everywhere in AI-generated code because they are easy to scaffold, and easy to get dangerously wrong. OWASP warns that some libraries have accepted unsigned tokens by default, using "alg":"none", in which case "an attacker would be able to forge their own JWTs"; a token must be rejected unless its signature verifies [13]. The underlying weakness is CWE-347, Improper Verification of Cryptographic Signature [14].

5. No rate limiting or lockout on login and password reset. A login form that accepts unlimited guesses is an open invitation to credential stuffing. OWASP's API guidance calls for "anti-brute force mechanisms" stricter than ordinary rate limits, and for treating "credential recovery/forgot password endpoints" as login endpoints for the same reason [15]. NIST requires verifiers to limit failed attempts to "no more than 100" before disabling an authenticator [16]; the NCSC recommends progressive delays, or, where lockout is used, allowing "between 5 and 10 login attempts" [17]. AI tools rarely add any of this unless asked.

6. Sessions that never really end. Logout that clears the browser but leaves the server-side session valid, or tokens that stay live for weeks. OWASP's guidance is that session identifiers need "at least 64 bits of entropy", that logout must invalidate the session "on both client and server sides", and that session timeout "must be enforced server-side" [18].

7. Secrets hard-coded into the source. An API key or a database password pasted straight into a committed file. This is CWE-798, Use of Hard-coded Credentials [19], and, as the GitGuardian figure above shows, AI-assisted commits make it measurably more likely [7].

8. Weak password rules, and storage that has not kept up. Guidance has moved on, and AI-generated defaults often have not. NIST's current Digital Identity Guidelines require single-factor passwords of "a minimum of 15 characters", and, notably, state that verifiers "SHALL NOT impose other composition rules" and "SHALL NOT require subscribers to change passwords periodically" [16]. A generated login that demands an eight-character password with a symbol and forces a ninety-day reset is following advice the standard now explicitly rejects.

The standard to hold AI-assisted authentication to

Every failure above has a well-established correct form, and none of it is new. The point of a senior review is to confirm the boring, load-bearing controls are actually present, not that the feature demos well.

• Enforce authorisation on the server, deny-by-default, on every route. Assume no request is allowed until something proves it is [8].
• Check ownership at the object level wherever a client-supplied ID reaches the database, and prefer unguessable identifiers over sequential ones [10].
• Do not reinvent authentication. OWASP's advice is explicit: use standard libraries for authentication, token generation and password storage rather than writing your own [15].
• Reject unsigned and unverified tokens. Make sure "alg":"none" is refused and every signature is checked [13].
• Rate-limit and lock out login and password-reset endpoints, and tie the counter to the account rather than only the source address [20].
• Store sessions server-side with real invalidation, and enforce timeouts you can prove [18].
• Keep secrets out of the repository and in a secrets manager [19].
• Treat your developers and pipelines as privileged users. The NCSC makes the point that anyone who can "commit changes to code repositories upon which your business relies" is a privileged user and should be governed as one [21]. An authorisation problem does not stop at the application login.

In our own audits, authentication and access-control findings are among the most frequent and the most serious we report, precisely because they pass every functional test. The feature works. The demo is clean. The gap only shows up when someone thinks like an attacker rather than a user, which is the work.

What to check this week

You do not need to stop using AI coding assistants. You need to check the parts they are known to skip.

1. Pick one sensitive endpoint and change the ID in the request. If you can read or edit a record that is not yours, you have an object-level authorisation gap [9].
2. Log out, then replay an old request with the previous session. If it still works, your logout is cosmetic [18].
3. Search the repository for keys and passwords. Anything you find in the source has already been in your version-control history and needs rotating, not just deleting [19].
4. Try to log in eleven times with the wrong password. If nothing slows you down or locks the account, there is no brute-force protection [15][16].
5. Find where you verify JWTs and confirm the signature is actually checked, and that "alg":"none" is rejected [13].

This is the same discipline as securing software you built or inherited, and it sits alongside the wider question of whether AI-generated code is safe to ship. If you want a structured view of what a review covers, how to review AI-generated code walks through it.

Frequently asked questions

What are the most common authentication vulnerabilities?

The most common are authorisation failures rather than login failures: missing server-side access checks, object-level gaps that let one user reach another's data, endpoints with no authentication, tokens accepted without a verified signature, no rate limiting on login, sessions that never expire, and hard-coded credentials. OWASP ranks broken access control as the top web risk [1].

What is the difference between authentication and authorisation?

Authentication proves who you are, through a password, token or second factor. Authorisation decides what you are allowed to do once you are in, such as reading a specific record or reaching an admin route. A system can authenticate you correctly and still fail to authorise you, which is the more common and more damaging mistake in AI-generated code [2].

Why is AI-generated code insecure?

Models reproduce the most common patterns in their training data, which favour the working feature over the security control that was often absent from the example too. Testing bears this out: Veracode found 45% of AI-generated samples failed security tests, and better models did not improve the result, so unreviewed AI code is a real risk [3].

How do you secure JWT authentication?

Verify the signature on every token and reject anything using "alg":"none", because a parser that accepts unsigned tokens lets an attacker forge their own [13]. Keep token lifetimes short, store signing secrets outside the code, and use a maintained library rather than hand-rolling verification. Treat the token as untrusted input until its signature proves otherwise [14].

Get a senior read on your authentication

Authentication and access-control flaws are dangerous precisely because they pass every functional test: the login works, the feature demos cleanly, and the gap only appears when someone checks what the tool left out. Our Vibe Code Audit is a bounded, fixed-price review by a named senior engineer that looks for exactly these findings in software built with AI, and our ongoing support keeps senior engineers on the systems you depend on. Book an audit.

Sources

1. OWASP Foundation, "A01:2021 - Broken Access Control", OWASP Top 10:2021. https://owasp.org/Top10/2021/A01_2021-Broken_Access_Control/
2. MITRE, "CWE-862: Missing Authorization", CWE version 4.20. https://cwe.mitre.org/data/definitions/862.html
3. Veracode, "We Asked 100+ AI Models to Write Code. Here's How Many Failed Security Tests" (2025 GenAI Code Security Report), 30 July 2025. https://www.veracode.com/blog/genai-code-security-report/
4. Pearce, Ahmad, Tan, Dolan-Gavitt and Karri, "Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions", IEEE Symposium on Security and Privacy 2022. arXiv:2108.09293. https://arxiv.org/abs/2108.09293
5. Perry, Srivastava, Kumar and Boneh, "Do Users Write More Insecure Code with AI Assistants?", ACM Conference on Computer and Communications Security 2023. arXiv:2211.03622. https://arxiv.org/abs/2211.03622
6. Snyk, "Secure adoption in the GenAI era". https://snyk.io/reports/secure-adoption-in-the-genai-era/
7. GitGuardian, "The State of Secrets Sprawl 2026", 17 March 2026. https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026/
8. OWASP Foundation, "Authorization Cheat Sheet", OWASP Cheat Sheet Series. https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
9. MITRE, "CWE-639: Authorization Bypass Through User-Controlled Key", CWE version 4.20. https://cwe.mitre.org/data/definitions/639.html
10. OWASP Foundation, "API1:2023 Broken Object Level Authorization", OWASP API Security Top 10:2023. https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/
11. MITRE, "CWE-306: Missing Authentication for Critical Function", CWE version 4.20. https://cwe.mitre.org/data/definitions/306.html
12. MITRE, "CWE-287: Improper Authentication", CWE version 4.20. https://cwe.mitre.org/data/definitions/287.html
13. OWASP Foundation, "JSON Web Token Cheat Sheet", OWASP Cheat Sheet Series. https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet.html
14. MITRE, "CWE-347: Improper Verification of Cryptographic Signature", CWE version 4.20. https://cwe.mitre.org/data/definitions/347.html
15. OWASP Foundation, "API2:2023 Broken Authentication", OWASP API Security Top 10:2023. https://owasp.org/API-Security/editions/2023/en/0xa2-broken-authentication/
16. NIST, "SP 800-63B-4: Digital Identity Guidelines: Authentication and Authenticator Management", 31 July 2025. https://csrc.nist.gov/pubs/sp/800/63/b/4/final
17. National Cyber Security Centre, "Password policy: updating your approach". https://www.ncsc.gov.uk/collection/passwords/updating-your-approach
18. OWASP Foundation, "Session Management Cheat Sheet", OWASP Cheat Sheet Series. https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
19. MITRE, "CWE-798: Use of Hard-coded Credentials", CWE version 4.20. https://cwe.mitre.org/data/definitions/798.html
20. OWASP Foundation, "Authentication Cheat Sheet", OWASP Cheat Sheet Series. https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
21. National Cyber Security Centre, "Introduction to identity and access management". https://www.ncsc.gov.uk/guidance/introduction-identity-and-access-management