10 vulnerabilities an AI can miss in a PHP application

Artificial intelligence is already part of many developers’ routines.

Today it’s common to use AI to generate PHP code, create endpoints, review functions, write tests, spot potential SQL Injections, or suggest security improvements.

And that’s extremely useful.

The problem starts when we trust AI as if it were a complete security audit.

An AI can analyze known patterns in code very well. However, application security depends on something that isn’t always present in the code we send it: context.

Who has permission to perform a given action?

What happens when a request is repeated 100 times?

Does that ID really belong to the authenticated user?

Can that file be accessed directly by the browser?

Can that external API be controlled by the user?

Can that operation be executed twice simultaneously?

These questions involve architecture, infrastructure, and especially business rules.

OWASP itself keeps Broken Access Control as the number one risk in the 2025 Top 10, precisely because many flaws aren’t related to an obviously insecure line of code, but to how the system should control what each user can do.

In this article, I’ll show 10 categories of vulnerabilities that an AI can miss in a PHP application.

1. IDOR and authorization flaws

Imagine a seemingly simple API:

php

#[Route('/api/clientes/{id}', methods: ['GET'])]
public function show(int $id): JsonResponse
{
    $cliente = $this->repository->find($id);

    return $this->json($cliente);
}

The code can be perfectly organized.

The query can be using parameters correctly.

There’s no evident SQL Injection.

Even so, there can be a serious vulnerability.

Imagine the authenticated user is client 10 and can simply do:

text

GET /api/clientes/11

If the application returns client 11’s data without checking authorization, there’s an access control flaw.

This type of vulnerability is known as IDOR (Insecure Direct Object Reference) and is directly related to OWASP’s Broken Access Control.

The problem is that an AI can analyze the method and conclude:

“The endpoint is authenticated and the code is correct.”

The important question isn’t just “Is the user authenticated?” — it’s “Is this user authorized to access this resource?”

A proper review should check something like:

php

if ($cliente->getUsuarioId() !== $usuario->getId()) {
    throw $this->createAccessDeniedException();
}

2. Mass Assignment

Another problem that can go unnoticed is the modification of properties the user should never control.

Consider:

php

$user->setData($request->toArray());

Or, in an attribute-based approach:

php

foreach ($request->toArray() as $field => $value) {
    $entity->{$field} = $value;
}

Imagine the entity has:

php

private bool $admin = false;

The developer may expect to receive:

json

{
    "name": "Fernando"
}

But an attacker may try:

json

{
    "name": "Fernando",
    "admin": true
}

If the application accepts properties that should be exclusively server-controlled, the user can modify privileged information.

An AI may even identify this pattern, but it often doesn’t know which fields are actually allowed by the business rule.

That’s why DTOs and explicit lists of allowed fields matter.

For example:

php

final class UpdateUserDto
{
    public function __construct(
        public readonly string $name,
        public readonly string $email,
    ) {
    }
}

In this model, it becomes much clearer what can be changed by the request.

The OWASP 2025 list also relates improper modification of dynamically controlled attributes to the software and data integrity failures category.

3. SSRF

SSRF stands for Server-Side Request Forgery.

It’s especially interesting because the code can look completely legitimate.

For example:

php

$url = $request->get('url');

$response = file_get_contents($url);

At first glance, there doesn’t seem to be a problem.

But who controls url?

An attacker could try to make the application access an internal address that shouldn’t be exposed.

For example:

text

http://127.0.0.1

or some internal infrastructure endpoint.

The problem becomes even more important in cloud environments, containers, and architectures with multiple services.

The OWASP 2025 list incorporated SSRF into Broken Access Control, showing that this type of vulnerability is closely related to control over which resources the application can access.

An AI looking only at the function may understand that it simply “fetches a URL”.

A specialist needs to ask:

Which URLs can the server access?

4. File uploads

Uploads are another classic example of seemingly simple functionality.

php

$file = $request->files->get('file');

$file->move('/var/www/uploads', $file->getClientOriginalName());

The AI may suggest improvements like checking the extension:

php

$allowed = ['jpg', 'png', 'pdf'];

But that still doesn’t mean the upload is secure.

There are several other questions:

Was the MIME type validated?

Was the actual content analyzed?

Can the file name contain ../?

Will the file be stored inside the public directory?

Can a PHP file be executed by the server?

Can an attacker send a huge file?

Is there a limit on the number of files?

Can the file overwrite another one?

Is the upload being processed by a vulnerable library?

Here again appears the difference between validating an input and protecting an entire feature.

5. Path Traversal

Consider a download feature:

php

$file = $_GET['file'];

readfile('/var/www/uploads/' . $file);

Seems simple.

However, if the parameter isn’t properly controlled, the user may try to manipulate the path.

The problem isn’t only the traditional ../.

You also need to consider:

path normalization;
symbolic links;
files outside the allowed directory;
differences between operating systems;
encodings;
file names controlled by the user.

An AI may suggest:

php

basename($file);

And that can help in certain scenarios, but it shouldn’t be treated as a universal solution.

The correct question is:

How do you guarantee the final resolved path stays inside the authorized directory?

Security shouldn’t depend only on sanitizing a string.

6. Race Conditions

This is one of the vulnerabilities that most easily goes unnoticed in an automated review.

Imagine an application that allows a coupon to be used only once:

php

if (!$coupon->isUsed()) {
    $coupon->setUsed(true);
    $order->applyDiscount();
}

Seems correct.

But imagine two simultaneous requests:

text

Request A → checks coupon → available
Request B → checks coupon → available
Request A → uses coupon
Request B → uses coupon

The problem isn’t necessarily in an “insecure” line.

It’s in the absence of an atomic operation or a proper concurrency mechanism.

Other examples:

two payment requests;
balance transfers;
sequential number generation;
benefit redemption;
duplicate record creation;
inventory usage;
queue processing.

An AI can review the entire method and not notice the behavior when two requests run at the same time.

This is an excellent example of a vulnerability that requires thinking about the system’s real behavior.

7. Lack of rate limiting

Imagine an endpoint:

php

#[Route('/api/login', methods: ['POST'])]
public function login(): JsonResponse
{
    // authentication
}

From a functional standpoint, everything may be working perfectly.

But how many attempts can be made?

1 per second?

10?

1000?

No limit at all?

Rate limiting isn’t just an infrastructure concern.

It’s also part of the application’s security design.

The problem can appear in:

login;
password recovery;
email sending;
SMS sending;
code generation;
expensive queries;
upload;
export;
endpoints that consume paid APIs.

In the API context, OWASP draws attention to Unrestricted Resource Consumption, when an API doesn’t adequately limit resource consumption and can be abused to generate downtime or operational costs.

An AI can generate a functional implementation of an endpoint without necessarily understanding how much that operation costs the system.

8. Insecure deserialization

PHP has serialization and deserialization mechanisms that can become dangerous when user-controlled data is treated as trusted.

A classic example:

php

$data = unserialize($_POST['data']);

The problem is that the content was provided externally.

Depending on the available classes and object behavior, this can open dangerous possibilities.

The same concept appears in modern applications when objects are automatically reconstructed from external data without proper validation.

It’s especially important to review:

php

unserialize()

serialization libraries, cache systems, queues, sessions, and automatic hydration mechanisms.

OWASP classifies deserialization of untrusted data under Software or Data Integrity Failures.

9. Business rule abuse

Perhaps the hardest category for an AI to detect.

Imagine an application that allows:

text

Create order
Cancel order
Request refund
Generate credit

Each endpoint can be individually protected.

But what if the user can do:

text

1. Create order
2. Receive credit
3. Cancel order
4. Keep the credit

There isn’t necessarily a SQL Injection.

There isn’t necessarily an XSS.

There isn’t necessarily an authentication error.

The problem is in the sequence of operations the system allows.

The OWASP API Security Top 10 draws attention to this problem with Unrestricted Access to Sensitive Business Flows: some APIs can expose business flows that can be abused automatically even when the individual implementation of the endpoints seems correct.

It’s exactly the type of problem that requires business knowledge.

The AI can analyze:

text

POST /pedido
POST /credito
DELETE /pedido

But it will hardly understand on its own that the combination of these operations creates fraud.

10. Insecure configuration

Finally, there’s a category of problems that doesn’t always appear in the PHP code.

For example:

APP_ENV=dev
APP_DEBUG=true

Or:

text

display_errors = On

Or even:

text

DocumentRoot /var/www/projeto/public/..

Other examples:

publicly accessible .env;
exposed debug directories;
database accessible from the internet;
overly permissive CORS;
cookies without Secure;
cookies without HttpOnly;
poorly configured session;
excessive file permissions;
exposed admin endpoints;
old PHP versions;
vulnerable dependencies.

OWASP placed Security Misconfiguration as A02 in the 2025 Top 10 and highlights that modern applications increasingly depend on configurations, making this type of problem especially relevant.

An AI can review:

text

src/
config/
templates/

and still fail to see:

text

Apache
Nginx
PHP-FPM
Docker
Cloud
Firewall
DNS
TLS
Database
Environment variables
CI/CD

What do all these examples have in common?

There’s a pattern among these vulnerabilities.

They depend less on:

text

"Is this line of PHP wrong?"

and much more on:

text

"Is this behavior allowed in this context?"

This is one of the main limits of using AI for security.

AI is excellent at identifying patterns.

It can find:

php

$sql = "SELECT * FROM users WHERE id = " . $_GET['id'];

and point out a SQL Injection.

But it can have much more difficulty noticing:

php

$orderRepository->find($id);

when the real problem is:

Can the authenticated user access this order?

The code can be technically correct.

The business rule can be wrong.

How to use AI more safely

The solution isn’t to stop using AI.

Quite the opposite.

AI can be an excellent security tool, as long as it’s used as one layer of the review, not the whole review.

When asking for a security analysis, it’s worth providing context.

Instead of:

text

"Analyze this code for vulnerabilities."

try:

text

"Analyze this PHP endpoint considering:

- authenticated user;
- per-owner access rule;
- possibility of concurrency;
- abuse through multiple requests;
- input validation;
- data exposure;
- business rules;
- integration with external services;
- production configuration.

Look for real vulnerabilities and explain how they could be exploited."

This completely changes the quality of the analysis.

It’s also important to combine AI with other tools and processes:

text

AI
↓
Code Review
↓
Automated tests
↓
SAST
↓
Dependency Scanning
↓
DAST
↓
Pentest
↓
Monitoring

None of these layers completely replaces the others.

Checklist before putting a PHP application into production

Before deploying, it’s worth asking at least these questions:

Authorization

Does each endpoint check authorization beyond authentication?
Can a user access another user’s resources by changing an ID?
Are there protected admin endpoints?

Data input

Is the data validated?
Is there protection against SQL Injection?
Are uploads actually secure?
Are file paths controlled?
Is external data treated as untrusted?

API

Is there rate limiting?
Are there pagination limits?
Is there protection against excessively expensive requests?
Do sensitive endpoints have protection against automation?

Session and authentication

Do cookies have HttpOnly?
Do cookies have Secure where applicable?
Is SameSite configured?
Does password recovery have expiration and abuse protection?

Infrastructure

Is APP_DEBUG disabled?
Are internal errors hidden from the user?
Is .env protected?
Are sensitive directories inaccessible?
Are PHP and dependencies up to date?

Business

Can operations that should be unique be repeated?
Is there protection against concurrency?
Can the user combine operations to circumvent a rule?
Are financial values validated on the server?

Conclusion

Artificial intelligence has changed how we develop software.

Today we can generate code, tests, and even security analyses in seconds.

But that doesn’t mean an application reviewed by AI is automatically secure.

The most interesting vulnerabilities usually appear exactly where the code looks correct:

in authorization, configuration, concurrency, resource abuse, and business rules.

That’s why the best strategy isn’t choosing between developer and AI.

It’s using AI as an additional tool within a larger security process.

In PHP applications, especially those that expose APIs, handle sensitive data, or perform financial operations, the question shouldn’t be just:

“Did the AI find any vulnerability?”

The most important question is:

“What didn’t the AI have enough context to notice?”

It’s on that second question that many security reviews truly begin.

References

OWASP Top 10:2025 — the current classification of the main security risks for web applications.
OWASP A01:2025 — Broken Access Control — includes authorization flaws, IDOR, CSRF, SSRF, and other access-control-related problems.
OWASP A03:2025 — Software Supply Chain Failures — covers risks related to dependencies, components, and the development chain.
OWASP API Security Top 10 — covers API-specific risks, including unrestricted resource consumption, authorization, and business flow abuse.