A full-source security review of a Laravel and Next.js CRM
A source-level review of a Laravel 10 API and a Next.js front end: authentication, authorisation, multi-tenancy, injection, file handling, secrets and the payment flow.
- Client
- PrimeSync CRM
- Sector
- Application security
- Shipped
- 2026
- Practice
- Application security
A full security review of PrimeSync CRM, covering both halves of the application: a Laravel 10 API and a Next.js front end. The scope was the source, not just the responses, and it ran across authentication, authorisation, tenant isolation, injection, file handling, configuration, secrets and the payment flow. Findings were ranked critical, high, medium and low, patched where we could patch them, and separated clearly from the items only the owner could action.
The problem
A CRM holding other businesses' customer data had grown feature-first. Nobody had read the whole codebase with an attacker's assumptions, and the questions that mattered most were the ones nobody had asked: can one tenant reach another tenant's records, and is anything secret sitting in the repository.
What we built
- 01
Read the code rather than probe the surface, so logic flaws in authorisation and tenancy surface rather than only the issues a scanner reports.
- 02
Rank every finding critical, high, medium or low, with the file and the reasoning attached.
- 03
Patch what could be patched in place, and keep those changes local and reviewable rather than pushed straight to production.
- 04
Separate out what only the owner can do: rotating leaked credentials, purging secrets from git history, and fixing production configuration.
- 05
Record what was checked and found sound, so the report says what is safe as well as what is not.
- 06
Note behaviour changes the patches introduce, so testing after the fix is not guesswork.
What it does now
- A written report with findings by severity, each tied to a file.
- Patches applied for the issues within our reach, held locally for review.
- An explicit action list for key rotation, git history and production config.
- A second pass that re-checked secrets status after the first round of fixes.
What people ask about this work.
What is the difference between a VAPT and a source code security review?
A VAPT probes the running application from outside and finds what an attacker can reach. A source review reads the code and finds logic flaws a scanner cannot see, such as an authorisation check that is missing on one endpoint or a tenant filter applied in the interface rather than the query. They answer different questions and the strongest assurance comes from doing both.
What do you do if you find secrets committed to a repository?
We flag it as critical, because rotation is the only real fix. Removing the key from the current files is not enough: it stays in git history and must be purged, and the credential itself has to be rotated at the provider. Those are steps only the owner can take, so we list them separately from the patches we apply.
Will a security review break my application?
Patches can change behaviour, which is why we document each change and keep fixes local for review rather than pushing them to production. The report includes a section on behaviour differences to watch for while testing, so the team knows what to re-check before releasing.