API Security Testing
Analyze API endpoints for authorization flaws, data exposure, and abuse opportunities.
View service detailsWeb Application Testing · Central Illinois
Scanners find injection. People find the logic flaws that cost you money.
Automated tooling is good at pattern matching and useless at understanding what your application is supposed to do. The findings that matter in a modern web application — a user reading another tenant's records, a checkout flow that can be replayed, a password reset that trusts a header — require someone who understands the business rules and then breaks them.
What web application testing actually covers
Web application penetration testing is an authenticated, manual assessment of a single application: its front end, its server-side logic, its authentication and session handling, and its authorization model. We test as multiple user roles, because the majority of high-severity findings in modern applications are authorization failures that are invisible to a single-account scan.
We follow the OWASP Web Security Testing Guide for coverage and the Application Security Verification Standard for depth, which means the assessment is repeatable and you can see exactly which control areas were exercised. But coverage frameworks only get you to the starting line. The work that produces the findings worth paying for is reading how your application actually behaves — how it constructs object references, where it trusts client-supplied state, what happens when a multi-step workflow is performed out of order.
Business logic is where we spend the most time and where automated tools contribute nothing. Can a user apply the same discount code fifty times? Can an order be shipped before payment settles? Can a trial account escalate itself to enterprise by editing a field the UI never exposes? These are not vulnerability classes with a CVE — they are consequences of how your specific application was built, and finding them requires a person who has read your workflows.
When you need this test
You are selling to enterprise customers
Enterprise security reviews and vendor questionnaires increasingly require an annual third-party application test. It is frequently the last blocker on a contract.
The application handles money, health data, or personal records
Anything with a payment flow, PHI, or a large volume of personal data justifies application-layer testing independent of any network assessment.
You just shipped a major release
New authorization models, new user roles, a new tenant architecture, or a rewritten authentication flow all introduce classes of risk that the previous test did not cover.
It is multi-tenant
Tenant isolation is enforced in application code, and application code has bugs. A single missing check is the difference between a SaaS product and a breach notification.
Your only testing to date has been a scanner in CI
DAST and SAST tooling in the pipeline is worth having and will not find broken access control, which is the most common serious finding in real applications.
What is in scope, and what is not
Included by default
- Authentication: login, registration, password reset, MFA, session lifecycle, SSO via SAML and OIDC
- Authorization: horizontal and vertical access control across every defined role
- Injection classes: SQL, NoSQL, command, template, XXE, and deserialization
- Client-side: stored and reflected XSS, DOM sinks, CSRF, clickjacking, CSP effectiveness
- Business logic: workflow sequencing, race conditions, pricing and quantity manipulation
- File handling, server-side request forgery, and third-party integration boundaries
Excluded unless contracted
- Denial-of-service and load testing
- Source code review, unless contracted as a complementary white-box engagement
- The underlying network and host infrastructure, covered by an external or internal test
- Phishing the application's real users
Methodology, phase by phase
Every engagement follows the same documented arc. The percentages below describe how testing time is typically distributed — the balance shifts with what we find, but the phases do not change.
Scoping and application walkthrough
Before testing beginsWe ask for a live demo rather than documentation. Thirty minutes of someone showing us what the application does and who uses it produces better testing than a hundred pages of specification, because it reveals the workflows that matter and the assumptions behind them.
- Guided walkthrough of core workflows with a product or engineering owner
- Provisioning of test accounts for every distinct role, including at least two accounts per role for isolation testing
- Agreement on the test environment, data reset procedure, and any destructive actions to avoid
Reconnaissance and threat modeling
Roughly 15% of testing timeWe map the application before attacking it: every route, parameter, and state transition, plus the technology behind it. Then we build a threat model that identifies which trust boundaries actually matter, so testing effort goes where impact is.
- Full crawl and manual traversal of the authenticated and unauthenticated application surface
- Framework, library, and dependency identification with known-vulnerability correlation
- Trust boundary mapping across client, server, database, and third-party integrations
- Identification of the high-value targets: payment paths, admin functions, data export, tenant boundaries
Authentication and authorization testing
Roughly 30% of testing timeThe largest single block of effort, because this is where the severe findings are. We test every privileged action from every unprivileged role, and every tenant's data from every other tenant's session, systematically rather than by sampling.
- Horizontal access control testing: can user A reach user B's objects by direct reference or parameter manipulation
- Vertical access control testing: can a standard user invoke administrative functions directly
- Session management review: token entropy, fixation, invalidation on logout and password change, concurrent session handling
- SSO and federation testing: SAML assertion manipulation, OIDC flow abuse, JWT signature and claim validation
Injection, client-side, and business logic testing
Roughly 35% of testing timeTraditional vulnerability classes are tested exhaustively across every input, and then we spend real time on the logic. Business logic testing has no checklist — it comes from understanding what your application promises and finding the sequence of requests that breaks the promise.
- Injection testing across all parameters, headers, and structured request bodies
- Client-side testing including stored and reflected XSS, DOM-based sinks, and CSP bypass
- Race condition testing against balance, inventory, invitation, and redemption endpoints
- Workflow abuse: step skipping, replay, negative and overflow quantities, state manipulation between steps
Reporting, developer walkthrough, and retest
5 business days after testing endsFindings are written for the developer who has to fix them. That means the vulnerable request, the code-level cause where we can determine it, the framework-appropriate fix, and a note about whether the same pattern likely exists elsewhere in the codebase.
- Report with full HTTP request and response captures for every finding
- Remediation guidance specific to your framework rather than generic OWASP prose
- Live technical walkthrough with the engineering team, recorded if you want it
- Free retest of remediated findings within 90 days
Standards this maps to
Auditors, insurers, and enterprise security reviewers all ask which methodology a test followed. These are the published frameworks our process is built on, and the report names them explicitly.
- OWASP WSTG
- The Web Security Testing Guide defines our coverage checklist. Every WSTG test category is exercised, and the report notes any category marked not applicable along with the reason.
- OWASP ASVS
- The Application Security Verification Standard sets the depth target. We default to Level 2, which is the appropriate bar for applications handling sensitive data.
- PTES
- The Penetration Testing Execution Standard defines the engagement arc we follow: pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, reporting.
- CVSS v4.0
- Every finding carries a CVSS v4.0 vector so the base score is reproducible, plus a separate business-impact rating, because a 9.8 on a decommissioned host is not your biggest problem.
What you receive
A human writes your report. Not a scanner export with a cover page, and not a template with your logo dropped into it.
- Findings with full request captures
- Every finding includes the exact HTTP request and response that demonstrates it, so a developer can reproduce the issue in minutes rather than guessing at the setup.
- WSTG coverage matrix
- A category-by-category record of what was tested. Where something was out of scope or not applicable, the report says so explicitly instead of leaving a silent gap.
- Framework-specific remediation
- Guidance written against your stack. If you are running Rails, you get the Rails fix; if you are on Next.js with Prisma, you get that. Generic advice to 'validate input' is not remediation.
- Systemic issue analysis
- Where a finding reflects a pattern rather than a one-off mistake, we say so and point at where else the pattern likely appears. Fixing the pattern is worth more than fixing the instance.
- Developer walkthrough call
- A working session with your engineers to go through findings, answer questions, and agree on fixes. Remediation quality goes up sharply when this happens.
- Attestation letter and retest report
- A shareable letter for customers and enterprise security reviews, plus verification of your fixes within the included 90-day retest window.
Typical scope and duration
- Typical testing window
- 5–15 business days
- Report delivery
- 5 business days after testing ends
- Total elapsed time
- 3–5 weeks from kickoff
- Common scope size
- 1 application, 2–6 user roles
- Access required
- Two test accounts per role, staging environment preferred
- Retest window
- 90 days, included
What drives the price
We quote a fixed fee after a short scoping call. No hourly billing, no change orders mid-engagement. These are the variables that move the number:
- The number of distinct user roles, since authorization testing scales with role pairs rather than role count
- How many unique workflows exist — an application with one core flow tests far faster than one with fifteen
- Whether the application is multi-tenant, which adds a full isolation testing pass
- The number of authenticated API endpoints behind the interface
- Whether you want white-box testing with source code access, which finds more but takes longer
Frequently asked questions
How long does a web application penetration test take?
Typical applications take 5 to 15 business days of active testing depending on the number of roles and workflows, with the report delivered 5 business days later. A single-role internal tool sits at the short end; a multi-tenant SaaS platform with an admin console, a customer portal, and a partner API sits at the long end.
Should we test production or staging?
Staging, if it genuinely mirrors production in code, configuration, and integrations. That lets us test destructive edge cases safely and manipulate data freely. If staging differs materially from production, we test production with agreed constraints, because testing an environment nobody uses tells you very little.
Do you need our source code?
No, and most engagements are black or gray box. Source access does make us faster and improves the precision of remediation guidance, so we offer it as an option. What we always need is working test accounts for every role — testing without credentials leaves the majority of the application untouched.
How is this different from running a DAST scanner?
A scanner is good at reflected injection and known-vulnerable dependencies, and structurally incapable of finding broken access control or business logic abuse, because it does not know what your application is supposed to permit. Broken access control is consistently the most common serious category we report. Keep the scanner in your pipeline; it does not replace this.
Will testing corrupt our data?
In staging, we test freely and you reset afterward. In production, we agree in advance on which actions are off limits, avoid destructive operations, and mark any test data we create so it is easy to identify and remove. We have never lost a client's production data and we design the engagement so that stays true.
Do you test the API behind the application?
The API endpoints the application itself calls are in scope by default, since that is how the application works. If you publish a separate documented API for customers or partners, with its own authentication and its own consumers, that warrants a dedicated API security assessment.
Related engagements
External Penetration Testing
Assess internet-facing assets to identify exploitable weaknesses before attackers do.
View service detailsMobile Application Testing
Evaluate mobile apps and connected APIs for insecure data flows and client-side abuse paths.
View service detailsNot sure this is the right test?
Tell us what you are trying to prove and to whom. A twenty-minute scoping call is usually enough to determine which engagement answers the question, and we will say so if the answer is a cheaper one.