CodeGuards.io reviews every commit diff in your PHP and Laravel repositories for exploitable vulnerabilities — including framework-specific patterns that generic scanners miss. Findings land on the GitLab merge request with severity, the exact line, and a fix suggestion your developer can apply in minutes.
Why PHP security review is different
PHP and Laravel codebases have a specific set of vulnerability patterns that show up repeatedly in real-world code review. Many of these are framework-specific: they depend on how Eloquent handles mass assignment, how Laravel's request object exposes input, or how specific helper functions behave when passed untrusted data.
Generic SAST tools often fire on broad patterns without understanding framework context — producing false positives for patterns that are safe in a properly configured Laravel application, and missing patterns that are only dangerous because of how the framework wires things together. CodeGuards.io is trained on real PHP and Laravel merge requests and understands the difference.
Passing $request->all() or $request->validated() directly to Model::create(), $model->update(), or Model::fill() without explicitly specifying $fillable is a common Laravel mistake. An attacker can add arbitrary fields — including is_admin, role, or email_verified_at — to a request and have them written to the database.
HIGH — Mass Assignment
File: app/Http/Controllers/UserController.php:34
- $user->update($request->all());
+ $user->update($request->only(['name', 'email', 'preferences']));
Broken Object-Level Authorization (IDOR)
Fetching a model by an ID from the request without checking that the authenticated user owns it is the most common access-control mistake in Laravel applications. CodeGuards.io detects when Model::find() or Model::findOrFail() is called with a request-supplied ID on a route that only requires general authentication.
Eloquent's query builder uses parameterized queries by default, but developers sometimes fall back to DB::select(), DB::statement(), or whereRaw() with string concatenation for complex queries. CodeGuards.io detects when user-controlled input flows into these raw query surfaces.
Sensitive data in logs
Logging full request payloads, authentication tokens, or payment-related fields is a common mistake in debug code that makes it to production. CodeGuards.io detects when Log::info(), Log::debug(), or similar calls include the full request body or known-sensitive field names.
Webhook and background job security
Laravel applications often process webhooks and queued jobs without sufficient validation. CodeGuards.io flags missing HMAC signature verification on webhook endpoints, unsafe deserialization in queue payload handling, and missing authorization in job dispatching logic.
Cryptographic mistakes
Usage of md5() or sha1() for password hashing or token generation, hardcoded encryption keys, and insecure random number generation using rand() instead of random_bytes() are all patterns CodeGuards.io catches in changed code.
Working with legacy PHP codebases
Many PHP teams work in codebases that predate modern Laravel versions or contain a mix of legacy procedural code and newer framework-based code. These codebases are often where the most significant security debt lives — and also where conventional SAST tools generate the most noise, because the full-codebase scan produces hundreds of findings on old code that no one is actively changing.
CodeGuards.io only reviews what changed. Connecting a ten-year-old codebase does not produce a backlog of historical findings. The first scan covers the next commit — nothing before it. Teams working in legacy PHP code often find this the most valuable aspect: they get security review on new changes without being blocked by years of accumulated debt.
For patterns that are present in old code and will not be fixed immediately — internal conventions, accepted technical debt, or compensating controls elsewhere in the stack — you can mark specific finding patterns as accepted with a policy note. CodeGuards.io scopes the suppression to that repo and stops reporting the same pattern on future scans.
How teams use CodeGuards.io alongside other PHP tooling
Most PHP security programs already include some combination of Composer audit (composer audit), PHPStan for static analysis, and periodic manual review or pentesting. CodeGuards.io fits into this stack as a continuous, commit-level layer — the thing that catches what slips through regular code review before it merges.
Composer audit / Dependabot — handles known CVEs in third-party dependencies. CodeGuards.io handles vulnerabilities in your own code.
PHPStan / Psalm — handles type safety and code quality. CodeGuards.io handles security-specific patterns that static analysis tools are not designed to detect.
Manual review — handles architectural concerns and business logic. CodeGuards.io handles the security checklist so reviewers can focus on those higher-level concerns.
Other supported languages
CodeGuards.io is not PHP-only. Teams using TypeScript, JavaScript, Python, Go, and Ruby can connect those projects and get the same commit-level security review. PHP and Laravel are highlighted here because the framework-specific detection patterns are particularly valuable — but the platform works across a mixed-language codebase with no extra configuration.
Frequently asked questions
Does CodeGuards.io understand Laravel's security features — like policies and gates?
CodeGuards.io is aware of common Laravel authorization patterns. It can distinguish between a route that uses $this->authorize() correctly and one that calls the same model method without an authorization check. It does not perform full data-flow analysis across the entire application but focuses on the most common patterns where authorization is missing in newly changed code.
We use a custom PHP framework. Does CodeGuards.io still work?
Yes. The detection library covers PHP-level patterns — raw query construction, input handling, session management, file operations — that apply regardless of framework. Framework-specific rules (Laravel, Symfony, Slim) add additional context on top of the base PHP rules.
Will it flag our test fixtures or seed data?
Occasionally. Test fixtures sometimes contain hardcoded credentials or simplified SQL queries that match security patterns. You can mark these findings as accepted with a note like "test fixture, not production code" and CodeGuards.io will stop reporting the same pattern in that repo.
How do we connect a self-hosted GitLab instance running our PHP projects?
The connection process is the same as for GitLab.com: paste a personal access token, specify your instance hostname, and select the projects. GitLab 14.0 and above is supported. See the workflow page for step-by-step setup.
Can CodeGuards.io fail the CI pipeline when it finds a critical vulnerability?
Yes. Add the CodeGuards CI runner to your .gitlab-ci.yml; it sends review and security bundles to POST /ci/reviews and POST /ci/scans. Details are on the workflow page.
Point it at your PHP or Laravel codebase.14-day trial · no card required · first finding in under 15 minutes.
