What This Is
Security testing is the work of probing your application the way an attacker would, finding the weaknesses, and reporting them with enough detail to fix. It covers the OWASP Top 10 (broken access control, injection, authentication failures, sensitive data exposure, security misconfiguration, vulnerable dependencies) and the application-specific risks that come with whatever your system actually does.
This is the finding half of security work. The fixing half is covered by Security Hardening, which closes the issues a security test surfaces. Most engagements pair the two: we test, we report, we fix. Some clients want only the test (because they have an internal team to remediate, or because an auditor requires an independent assessment); others want only the hardening (because they already have a list of known issues). Both are fine.
Security testing is a different discipline to functional testing. A unit test asks “does the code do what I designed it to do.” A security test asks “does the code do anything I did not design it to do.” That is a much harder question, because the surface of unintended behaviour is enormous. Real security testing requires adversarial thinking, not just thorough thinking.
When You Need This
Security testing is the right service when:
- A client, partner, regulator, or insurer is asking for evidence that your application has been independently tested for security issues
- You are handling sensitive data (payment details, health records, personal information) and need confidence that the application protects it
- You have had a security incident (a breach, a near-miss, a suspicious log entry) and need to know whether other vulnerabilities are present
- Your application was built quickly and security was not the priority during construction
- You are launching a new feature with elevated risk (a payment flow, a file upload, an admin panel) and want it tested before it goes live
- An internal change (a new dependency, integration, or authentication library) has expanded the attack surface and you want to verify nothing has been opened up
This is not the right service if you need a 24/7 security operations centre or ongoing intrusion detection. We test applications; we do not run a SOC. For continuous monitoring, we can integrate the application with appropriate tooling and recommend a managed provider.
How We Work
Security testing engagements follow a structured methodology, not a tool dump. Running an automated scanner and emailing the report misses the point entirely: it produces volumes of false positives and overlooks the application-specific issues that actually matter. We combine automated scanning with manual exploration, because the two find different classes of bug.
We map the attack surface first. Authentication flows, password reset, session management, file upload, file download, search, admin panels, API endpoints, third-party integrations, error pages, and any feature that touches sensitive data. The mapping itself often reveals issues: forgotten endpoints, debug routes left enabled, admin features accessible to non-admins.
We test access control rigorously. Broken access control is consistently the most prevalent and most damaging vulnerability class in modern web applications. We test horizontal authorisation (can user A see user B’s data) and vertical authorisation (can a regular user reach admin functionality) systematically across every authenticated path.
We look at the application-specific logic, not just the framework. Frameworks like Laravel and Express prevent many common vulnerabilities by default: CSRF, SQL injection through ORM, XSS through template escaping. The remaining bugs are in the business logic: pricing calculations that allow negative values, voucher codes that can be reused, role assignment that can be self-applied. Those bugs are unique to your application and require manual analysis to find.
We produce a report that helps fix the issues, not just list them. Each finding includes severity rating (CVSS where applicable), reproduction steps, the underlying cause, and a specific remediation path. The report is something the engineering team can act on directly. For background on what this process covers, see what penetration testing involves.
What You Get
- Threat model for the application, identifying the highest-value attack paths
- OWASP Top 10 assessment with reproducible findings for each applicable category
- Access control audit covering every authenticated role and resource
- Application-specific logic review: pricing, vouchers, credits, permissions, anywhere that business rules meet user input
- Dependency vulnerability scan with prioritised update recommendations
- Penetration testing report with severity ratings, reproduction steps, and remediation guidance
- Optional remediation engagement, transitioning to Security Hardening to fix the findings
Technologies We Use
- OWASP ZAP and Burp Suite for dynamic application security testing
- Composer Audit and npm audit for dependency vulnerability scanning
- Semgrep and PHPStan security rulesets for static analysis
- Manual exploration with a proxy-based interception toolchain (the highest-value tool we use)
- Laravel security primitives for context when assessing Laravel-specific applications: Sanctum, Spatie Permissions, encryption, CSRF tokens
Related Systems
Security testing is most critical for systems handling sensitive data. A client portal where multiple clients share infrastructure must have airtight tenant isolation. A contract management system handling legal documents needs robust access controls and integrity guarantees. A password vault needs the highest level of scrutiny applied to every endpoint. For systems that need to stay monitored after testing, a security monitoring system is the natural next step.
Talk to Us About a Security Assessment
Security testing is one part of our broader software testing practice. If you need an independent security assessment of your web application, get in touch and we will scope a test that fits the actual risk, not a generic checklist run.
Two Different Products, Frequently Confused
Automated scanning runs tools against your system and lists known issues in known software. Cheap, repeatable, can run on every deployment. Genuinely useful and it cannot reason.
A human test is a skilled person deliberately trying to break in. They chain small weaknesses into a real attack in a way tools cannot: a version number here, a permissive setting there, an error message revealing a path.
Quotes for the second that deliver the first are common. The tell is in the findings. A real test describes a path with steps. A scan lists issues with severity ratings and no narrative.
What Scanners Miss
Logic flaws, which are the ones that matter most in business software.
The classic: a user opens their own record at /invoices/1049, changes it to 1048, and sees somebody else’s. Nothing about that request is malformed. The system checked they were logged in and never checked whose data they asked for.
A scanner cannot find that, because nothing is technically wrong. Only the business rule is missing. It requires somebody who understands what the rule should be, which is why human testing exists and why it costs more.
You can test this one yourself in a minute, and it is a fair thing to ask any supplier to demonstrate is impossible.
The Order That Makes Sense
Cheapest first, because a test on a system with obvious gaps produces an expensive report confirming what was already knowable.
Dependency scanning in the pipeline. Most vulnerabilities are in third-party components, they are published, and this catches them for free on every build.
Second factors and access review. Not testing, and they remove more risk than any test finds.
Automated application scanning, which catches the common patterns.
Then a human test, once the obvious is dealt with and the stakes justify it.
What Moves The Price
Scope. Application only, or infrastructure, or the people. Phishing is frequently the fastest route in and is often excluded by default.
Whether authenticated testing is included. Testing as a logged-in user finds considerably more than testing from outside, and it requires accounts and coordination.
Whether a retest is included. A test without one leaves you with a list rather than an outcome. It should be.
How much remediation is in scope, as distinct from finding.
Where This Goes Wrong
Testing too early, before the cheap measures are in place.
A report nobody acts on. The most common outcome.
Treating severity ratings as a work queue. They describe a generic worst case, not your situation. Something rated high requiring administrator access may matter far less than something rated medium any visitor can trigger.
Assuming it is a one-off. The report describes one system on one day. Code shipped next month is untested.
Questions To Ask Whoever Quotes For This
- Is this a human test or a scan? Ask what proportion is manual.
- Is authenticated testing included?
- Is a retest after fixes included?
- What is out of scope? Phishing and infrastructure are the common exclusions.
- Will you show us how to reproduce each finding? Otherwise fixing is guesswork.
A Brief You Can Send Anyone
The system: [what it does, what data it holds]
Who uses it: [public, customers, staff]
What worries us: [or who is asking, a customer or auditor]
What is already in place: [2FA, patching, scanning]
Compliance obligations: [if any]
What a breach would cost: [regulatory, contractual, reputational]
Environment available for testing: [staging or production]
How We Approach It
Dependency scanning wired into the pipeline first, because it is free and continuous. Then the access basics. Then testing, prioritised by what an attacker actually gains rather than by a generic rating.
Remediation matters more than discovery, so we would rather quote for fixing than for a report. The ongoing work sits under security hardening.
The wider testing picture is on the testing page.
