Every web application that takes a login, a payment or a customer's data is a target, whether or not anyone has noticed it yet. A security test is how you find the weaknesses before someone else does. This guide explains the kinds of test, what they look for, and how to tell a useful report from a long one.
01Three kinds of test
- Vulnerability scan: automated tools check for known weaknesses — outdated components, missing headers, common misconfigurations. Fast, cheap, shallow. Finds the obvious; misses anything that needs understanding.
- Penetration test: a person, with permission, tries to break in the way an attacker would, chaining small weaknesses into a real breach. Finds logic flaws, broken access control and the things scanners cannot see. The one that matters before launch.
- Code review: reading the source for insecure patterns — how inputs are handled, how secrets are stored, how permissions are checked. Catches problems a black-box test might not reach.
A serious engagement combines them: scan for breadth, test for depth, review where the risk is highest.
02What a test looks for
The industry's shared checklist is the OWASP Top 10. In plain language, the categories are:
- Broken access control: can a user see or change something that isn't theirs by editing a URL or an ID?
- Injection: can text typed into a form be made to run as a database query or a command?
- Authentication failures: weak passwords allowed, sessions that never expire, logins that can be brute-forced.
- Insecure design: a flow that is exploitable by its nature — a password reset that leaks whether an account exists, a discount code with no limits.
- Security misconfiguration: default credentials, verbose error pages, debug modes left on, permissive cloud storage.
- Vulnerable and outdated components: libraries and frameworks with known holes.
- Cryptographic failures: data stored or sent without protection, or with weak protection.
- Software and data integrity failures: updates or dependencies that can be tampered with.
- Logging and monitoring failures: a breach that nobody would notice.
- Server-side request forgery: tricking the server into fetching internal resources.
03Before the test: scope and permission
A test is only legal and only useful when it is agreed in writing: which systems, which accounts, which times, what is out of bounds (production payments, third-party services you don't own). Good testers insist on this; be wary of any who don't.
04What a good report contains
- Each finding with a severity that reflects real impact, not just the tool's default
- Exact steps to reproduce it, so your developers can see it themselves
- What an attacker could actually do with it
- Specific guidance to fix it, not a generic recommendation
- A retest after the fixes, confirming they worked
- A plain summary a non-technical owner can read in five minutes
Fifty findings padded with low-severity scanner output is not better than eight real ones. Judge a report by what you can act on.
05What a test does not guarantee
A clean test means no one found a way in during that window with that scope. It does not mean the application is secure forever, and it does not cover what changed after the test. Treat it as a measurement at a point in time.
06How often
- Before launch of anything that handles logins, payments or personal data
- After any major change: new features, new integrations, a rewrite
- On a regular cycle for anything live, with scans more often than full tests
- Immediately when a serious vulnerability is announced in something you use
In short
- Scan for breadth, penetration test for depth, review code where the risk is highest.
- Broken access control and injection are the findings that matter most in practice.
- Agree scope and permission in writing before anyone starts.
- Judge a report by reproducible, actionable findings and a retest — not by its length.
Questions
Is a security test the same as compliance?
No. Compliance frameworks ask whether controls exist; a security test asks whether they work. You usually need both, but a certificate does not mean the application cannot be broken.
Will testing break our production system?
A well-scoped test on a staging copy should not. Testing against production is sometimes necessary but is agreed explicitly, with limits, and usually outside peak hours.
What if we built the application ourselves?
Then an outside test is more valuable, not less: the people who built it share its blind spots.
Sounds like your problem?
Tell us about it. We'll say honestly whether the swarm can help, and what it would take.
More guides