Web Application Penetration Testing, From the Source Code Up
A web application test should answer one question: what could an attacker do with your application, its logins and its APIs? We answer it from the source code up. You give us the code under NDA, we build and run it in an isolated NetSys sandbox with no path to production, and engineers review the code and attack the running build. This is the Tier 2 engagement that sits behind our free external network test.
The short answer
Web application penetration testing is an authorized attack on your application, its logins and its APIs to prove which flaws an attacker could use. NetSys tests from the source code up: we build your application in an isolated sandbox under NDA, review the code, attack the running build, write up each finding with the fix, and retest after you patch.
Closest related page: Penetration testing services and the free external test. That page covers the free Tier 1 external network test and how the two tiers compare; this one covers the Tier 2 test of your application's code and running build.
Businesses that build or run their own software: a customer portal, a SaaS product, an internal tool that holds client data, or the API behind a mobile app. The trigger is usually a customer's security questionnaire, a SOC 2 or PCI DSS assessment, an investor's due diligence, or a major release nobody has tested from an attacker's side.
The free external test cannot answer that question, because it stops at what your business exposes to the internet. Application flaws sit behind the login: one customer reading another's records, a form that passes input straight to the database, an API that skips a permission check. Finding those takes the code, a running build and an engineer's time, which is why this test is scoped and quoted per application.
Read the Code, Then Attack the Running Build
A short technical call sets the scope: the application, its user roles, its APIs, the languages and frameworks, and how it is built and deployed. You then give us the code under a signed NDA, as a repository grant or an archive, and we build and run it in an isolated NetSys sandbox that has no connection to your production systems, customers or data. Engineers review the code for the flaws that matter, attack the running application and its APIs, and scan dependencies, committed secrets and configuration. Each finding is written up with its severity, reproduction steps and the specific fix, and we retest once you have patched. When the engagement closes, the code and the sandbox are deleted.
What a web application penetration test covers
Code review for injection, broken authentication and business-logic flaws
Reading the code finds what testing from outside can miss.
- Injection: input that reaches a database query, a command or a page without being handled safely
- Broken authentication and authorization: sign-in, session and permission checks a user can get around
- Business-logic flaws: features used in an order or a way the application never expected
- Insecure deserialization and other places the application trusts data it should check
Testing the running app and its APIs
The build in our sandbox, attacked the way a user or an attacker would reach it.
- The application's pages, forms and logins, exercised in the running build
- The APIs behind the application, called directly rather than only through the screens
- Findings from the code review confirmed against the running build, so each one is shown to work rather than assumed
- No traffic to your production systems: the test runs entirely inside our sandbox
Dependencies, secrets and configuration
The supply-chain paths attackers use.
- Third-party libraries checked for known vulnerabilities, and for components nobody maintains any more
- Secrets committed to the repository, such as passwords, API keys and tokens left in code
- Configuration checked for what OWASP lists under misconfiguration: unchanged default accounts, error messages that reveal stack traces and missing security headers
- Each finding tied to the file or component it lives in, so developers can fix it at the source
Findings, fixes and a retest
A report your developers can act on, then proof the fixes hold.
- Findings ranked by real-world risk, each with severity, evidence and reproduction steps
- The specific fix for each finding, written for the developers who will make it
- A retest after you patch, with the result recorded against each finding
- Code and sandbox deleted when the engagement closes; the findings go to you and nobody else
Why software teams choose NetSys for application testing
Tell us what the application does, the languages and frameworks it uses, how many user roles and APIs it has, and what prompted the test. A NetSys engineer will tell you whether we can build and run it in our sandbox and what the scope would cover. Call 845-203-3914 or request a scoping call.
Who does the work: meet the NetSys team on our About page.
- Your code never leaves the sandbox: NDA, isolated infrastructure, no production access, deleted at close
- Engineers read the code and attack the running build, so you get demonstrated findings rather than a scanner export with a logo on it
- Every finding comes with reproduction steps and the specific fix, then a retest
- Scoped on a short technical call and quoted per application, with no rate card
- If we cannot build and run your platform, we say so on the scoping call rather than fake a test
- A firm defending business networks since 1998, from one office in Brooklyn
Black box, grey box or white box: why we test from source
Testers describe access in three levels. The more the tester can see, the more the test can prove:
| Level | What the tester gets | What it can miss |
|---|---|---|
| Black box | No information: the application as an outsider sees it | Anything behind the login, and code paths a tester cannot reach from outside |
| Grey box | Credentials and documentation, with partial knowledge of how the application works | Flaws in code the tester never triggers, and logic only the source explains |
| White box | The source code and the architecture, plus a running build | The least: the code shows what the application does, though design flaws still need a person reading it |
Our Tier 2 test is white box: we build the application from your source and test both the code and the running build. The OWASP Web Security Testing Guide notes that source code review finds vulnerabilities a black-box test would miss, naming flawed business logic, access control problems and cryptographic weaknesses among them.
How the test maps to the OWASP Top 10:2025
The OWASP Top 10 is a consensus list of the most critical security risks to web applications, and 2025 is the current edition. The risks our test looks for, and where:
| OWASP risk | What it means | Where our test looks for it |
|---|---|---|
| A01 Broken Access Control | Users acting outside their permissions, such as opening another customer's account or calling an API without the right role | Code review of permission checks, then requests in the running build that try to cross them |
| A02 Security Misconfiguration | Missing hardening or insecure settings anywhere in the application stack | Configuration scanning and review of the build's settings |
| A03 Software Supply Chain Failures | Vulnerable, unmaintained or compromised third-party components | Dependency scanning of the libraries the application uses |
| A05 Injection | Untrusted input run as a command by a database, browser or shell, including SQL injection and cross-site scripting | Code review of input paths, then injection attempts against the running build |
| A06 Insecure Design | Design and business-logic flaws that a perfect implementation would not fix | Reading how features are meant to work, then using them in ways the design did not expect |
| A07 Authentication Failures | Weak sign-in and session handling, and credentials hard-coded into the application | Review of the sign-in and session code, and secret scanning for credentials left in the repository |
| A08 Software or Data Integrity Failures | Trusting code or data without checking it, including insecure deserialization | Code review of where the application accepts serialized data or updates |
The table covers the risks our Tier 2 scope names. Ask on the scoping call how A04 Cryptographic Failures, A09 Security Logging and Alerting Failures and A10 Mishandling of Exceptional Conditions would be handled for your application; any quote should say which categories it covers.
How a sandboxed application test runs
Every Tier 2 engagement follows the same order, from the scoping call to deleting the code:
- Scoping call: the application, its user roles, APIs, languages and frameworks, and how it is built, agreed in writing
- NDA and handover: you grant repository access or send an archive, under a signed NDA
- Isolated build: we build and run the application in a NetSys sandbox with no path to your production systems, customers or data
- Static review: engineers read the code for injection, authentication and authorization flaws, insecure deserialization and business-logic weaknesses
- Dynamic testing: the running build and its APIs are attacked, and dependencies, secrets and configuration are scanned
- Report: each finding with severity, evidence, reproduction steps and the specific fix
- Retest: once you have patched, we test the fixes and record the result
- Close: the code and the sandbox are deleted, and the findings stay with you
Because the test never touches production, it needs no change window and cannot take your live application down.
What the findings report contains
An illustration of one finding, written for this page. It is not a finding from a client report:
| Field | What it tells you | Illustrative example |
|---|---|---|
| Finding | What was found, in one line | A customer can open another customer's invoices by changing the number in the address |
| Severity | How urgent it is, ranked by real-world risk | High |
| Evidence | What the test observed, so your developers can check it | In the sandbox build, a request for invoice 1042 made as customer A returned customer B's invoice |
| Where it lives | The file or component that causes it | The invoice endpoint checks that the user is signed in, not that the invoice belongs to them |
| Fix | The specific change that closes it | Check on the server that the record belongs to the user before returning it |
| Retest | Whether the fix was confirmed | Tested again after the patch, with the result recorded here |
Every report also states what was in scope, which build was tested and what was not tested, so nobody reads more into it than the test supports.
How web application testing is priced
We publish no rate card. A web application test is quoted per application after a short technical call, and these inputs move the number:
| Factor | Why it moves the price |
|---|---|
| Application size | More pages, features and code mean more to review and attack |
| User roles | Each role is another set of permissions to check |
| API endpoints | Each endpoint is tested directly, not only through the screens |
| Languages and frameworks | Each stack in the codebase needs its own review |
| Build reconstruction | How much of the build we have to recreate before the application runs in the sandbox |
Comparing quotes? What a penetration test costs, and how to compare quotes.
The quote names the scope, the deliverables and the retest before any work starts.
Web Application Penetration Testing FAQs
What is web application penetration testing?
Web application penetration testing is an authorized, controlled attack on an application, its logins and its APIs to prove which flaws an attacker could actually use. It goes further than a scan: an engineer chains weaknesses together and shows what they reach. NetSys tests from the source code up, reviewing the code and attacking a running build in our sandbox, then retesting after you fix.
Do you test our live site or a copy?
A copy. We build the application from your source in an isolated NetSys sandbox and attack that build, so the test never touches your production systems, customers or data, and it needs no change window. If a customer or auditor asks specifically for a test of the deployed application, tell us on the scoping call and we will say what our sandboxed test can and cannot show.
Which languages and frameworks can you test?
Any codebase we can build and run: web applications, APIs, mobile backends, integrations and internal tools across the common stacks. If your platform is unusual, the scoping call is where we say so, because we would rather decline a test than fake one. Bring the repository structure and the deployment model to that call.
Is our source code safe with you?
You provide the code under a signed NDA, as a repository grant or an archive. We build and run it in an isolated NetSys sandbox with no connection to your production systems, customers or data, and the code never leaves that sandbox. When the engagement closes, the code and the sandbox are deleted, and the findings go to you and nobody else.
Will the report satisfy SOC 2 or a customer security questionnaire?
It can support either, but acceptance is the auditor's or the customer's decision. The report states the scope, the build tested, what was not tested, each finding with reproduction steps and the fix, and the retest result. Before you commission the test, ask the auditor or customer what scope and evidence they need, and bring that to the scoping call so the scope matches.
How is this different from the free external test?
The free Tier 1 test looks at your business from the internet: the domains, public systems, remote access and logins you expose, within an agreed scope and with no credentials. This Tier 2 test looks inside one application: its code, its running build and its APIs, in our sandbox. Start with the free test, and add application testing for the software you build or run.
Do you retest after we fix the findings?
Yes. A retest is part of the engagement: once you have patched, we test each reported finding again and record whether the fix holds. Ask about the retest window on the scoping call, so its timing fits your release plan.
Does PCI DSS require application penetration testing?
For applications in a cardholder data environment, yes. PCI DSS v4.0.1 requirement 11.4 calls for a documented penetration testing method that includes application-layer testing for, at a minimum, the attacks listed in requirement 6.2.4, with internal and external tests at least once every 12 months and after significant changes, and testing repeated to confirm fixes. Your SAQ type and your assessor decide what applies.
Sources and technical references
- OWASP Web Security Testing Guide v4.2, the current stable release
- OWASP WSTG v4.2 introduction: source code review, penetration testing and black, grey and white box testing
- OWASP Top 10:2025, the current edition
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
- Microsoft Learn: PCI DSS Requirement 11, quoting the 11.4 penetration testing requirements
- PCI Security Standards Council: PCI DSS v4.0.1, a limited revision with no new or deleted requirements
Guides on this topic
- Penetration testing services and the free external test
- What a penetration test costs, and how to compare quotes
- Penetration testing vs vulnerability scanning for a small business
- What penetration testing is, and how the main test types differ
- Vulnerability management between tests
- SOC 2 readiness and audit preparation
- PCI DSS compliance for merchants
- Internal and tenant security assessments
Bring the application and the question you need answered.
Tell us what the application does, its stack, its user roles and APIs, and who is asking for the test. We will confirm whether we can build it in our sandbox, agree the scope in writing and quote it before any work starts.