Security audit and penetration test

A web application security audit and penetration test is manual and automated testing of a web application and its cloud infrastructure, carried out the way an attacker would approach them, within a scope and rules of engagement agreed in writing. It ends with findings rated by severity, each with evidence and a fix, a retest after your fixes, and a summary you can share. It is for SaaS companies facing their first enterprise security questionnaire, fintech and health products handling sensitive data, and teams preparing for SOC 2 or ISO 27001.

I completed the Google Cybersecurity Specialization. The testing method follows the OWASP Web Security Testing Guide, and findings are mapped to the OWASP Top 10:2025 and the Application Security Verification Standard where they apply.

A vulnerability scan is automated checking for known issues; it gives breadth and nothing more. A penetration test adds manual work: chaining issues together and testing access control and business logic the way a person would. A security audit, as I run it, is the scoped engagement around both: automated scanning for breadth, the manual testing, an infrastructure review, a ranked report and a retest.

Before any testing we agree in writing: the targets (domains, APIs, mobile back ends, cloud accounts), the test accounts for each role, the time windows, the source addresses I'll test from, what is out of bounds, and who to call if testing finds something serious. Testing runs against staging where possible. Where it must touch production, limits are agreed in advance and destructive tests are never run there.

Automated scanning gives breadth: known vulnerabilities in dependencies and containers, exposed services, missing headers and weak TLS. Manual testing goes where the real risks usually hide. Authentication and session handling. Authorization, above all whether one user can read or change another user's data by changing an identifier; broken access control is the first entry in the OWASP Top 10:2025. Injection of every kind, server-side request forgery, file uploads, business-logic abuse such as skipping a payment step, and secrets in code, images or front-end bundles.

The infrastructure review covers IAM roles and keys, network rules, storage permissions, TLS, security headers and how secrets are stored and rotated.

Each finding has a title, a severity, the affected component, the evidence, the steps to reproduce, the impact in plain words and a specific fix. Severity uses the CVSS scale for the technical score, adjusted for your context. An executive summary sits at the front for customers and investors. A walkthrough of what a penetration test report contains shows the format with a fictional finding.

It is not a certification. SOC 2 and ISO 27001 need an accredited auditor; I help you get ready for one. It is also not a compliance opinion: I test and document technical measures, and your counsel decides which obligations apply.