sales-inquiry@itecsonline.com|(214) 444-7884
Talk to ITECS

Web application penetration testing in Dallas

Manual testing of your web application against the OWASP Top 10, at a flat fee. Every test includes a readout call and one retest within 90 days of the report.

Scope your testSee how the flat fee works

Manual · signed-in and signed-out

What a web application penetration test covers

A web application penetration test is a manual, authorized attempt to break into your application. We test signed-in and signed-out, check that each user role reaches only its own data, and look for ways to abuse your business logic.

The test also covers your application’s own API, up to the endpoint limit of your tier. If an API stands on its own with no user interface, our API penetration test is built for it. For iOS and Android apps, see mobile app penetration testing.

  • Signed-in and signed-out testing
  • Every user role checked against the others
  • Business-logic abuse a scanner can’t model
  • Your app’s own API, within your tier
Illustration of an access-control test across roles and tenants. Not a client system.

Included in every test

What you get

Leadership gets an executive summary. Your developers get every finding with its risk rating and evidence, plus the steps to fix it. We walk your team through the results on a readout call, and after your fixes are in, we retest the reported findings once.

Not included

  • Source code review
  • Fixing the findings (you get the fix steps)
  • More retest rounds, or a retest after 90 days. We quote these as a fixed fee.

  • Scoping call and rules of engagement

    We agree on the scope and the environment, then write both into rules of engagement before testing starts.

  • Executive summary

    A short read for leadership: what we tested, what we found and which risks matter most.

  • Risk-rated findings

    Every finding with its risk rating, the evidence behind it and the steps your developers need to fix it.

  • Readout call

    We walk your team through the results and answer questions about each finding.

  • Letter of attestation

    For your SOC 2 auditor or a customer’s security questionnaire.

  • One retest

    After your fixes, we retest the reported findings once, within 90 days of the report.

Flat fee

How the flat fee works

The fee is per application, tested in one environment. Your tier depends on the size of the app, and if it goes past any limit, the test moves up a tier.

  • One flat fee per application

    Set by the size of the app and tested in one environment. No hourly or day rates.

  • Past a limit, up one tier

    If the app goes past any limit of its tier, the test moves up a tier.

  • Past Large, a fixed quote

    More than one application, microservices or anything past Large gets a fixed-fee quote after scoping.

Web application penetration testing tiers
TierPages or screensUser rolesAPI endpointsTypical fit
SmallUp to 25Up to 2Up to 25—
MediumUp to 75Up to 4Up to 75Single sign-on, MFA or payment flows
LargeUp to 150Up to 6Up to 150Multi-tenant platforms
Beyond LargeQuotedQuotedQuotedMore than one application, microservices, or past the Large limits

Tests start at $6,990 for the Small tier. Anything past Large gets a fixed-fee quote after the scoping call. Either way, you know the price before testing starts.

How the test runs

How the test runs

The same six steps for every application test. Nothing gets tested until the scope is in writing, and nothing in the report goes unexplained.

  1. 01

    Scoping call

    We agree on what’s in scope and which environment we test, and confirm your tier and the flat fee before any testing starts.

  2. 02

    Rules of engagement

    Scope, environment and test window go into written rules of engagement. We test only what they cover.

  3. 03

    Manual testing

    We test signed-in and signed-out against the OWASP Top 10, including access control across your user roles, your business logic and the app’s own API.

  4. 04

    Report

    An executive summary for leadership, and every finding with its risk rating, evidence and fix steps for your developers. It arrives on the date set in your rules of engagement.

  5. 05

    Readout call

    We walk your team through the results and answer questions about each finding.

  6. 06

    Retest

    After your fixes are in, we retest the reported findings once, within 90 days of the report.

Mapped to OWASP

What we test

We test against the OWASP Top 10:2025, the current edition of OWASP’s list of the most serious web application security risks. Every category below is part of every test, along with the business logic that’s specific to your application.

OWASP Top 10:2025 categories and what the web application test checks for each
OWASP Top 10:2025What we test
A01:2025Broken Access ControlWhether each role and each tenant reaches only its own data and functions, including when we change record IDs in requests.
A02:2025Security MisconfigurationDefault settings, detailed error messages, exposed admin pages and missing security headers on the running app.
A03:2025Software Supply Chain FailuresOutdated or vulnerable third-party components we can identify from the running app. A full dependency review needs source access, which this test doesn’t include.
A04:2025Cryptographic FailuresHow data is protected in transit, and whether sensitive data shows up where it shouldn’t, like in URLs or responses.
A05:2025InjectionWhether input in forms, URLs and API calls can change the queries or commands your server runs.
A06:2025Insecure DesignBusiness-logic flaws, like skipping a payment step, reusing a one-time code or approving your own request.
A07:2025Authentication FailuresSign-in, MFA, password reset and session handling, for every role in scope.
A08:2025Software or Data Integrity FailuresWhether the app trusts data it shouldn’t, like values from the browser that set a price or a permission.
A09:2025Security Logging and Alerting FailuresLogging and alerting aren’t visible from outside the app. Your rules of engagement record when we tested, so your team can check what its monitoring caught.
A10:2025Mishandling of Exceptional ConditionsHow the app behaves when requests fail or arrive out of order, and whether errors leak details or leave it in an unsafe state.

Audit and customer evidence

Testing for SOC 2 and customer questionnaires

If a SOC 2 audit or a customer’s security review is driving the test, tell us on the scoping call. We scope the test to the system your auditor is looking at and write the attestation letter for it.

You can share the letter with an auditor or a customer without handing over the full report, and attach it to the security questionnaires that ask whether your application has been tested.

Your auditor decides what evidence it accepts. We don’t promise a SOC 2 outcome, and no single test makes a company compliant.

ITECS

Letter of attestation

Date:

To whom it may concern,

ITECS performed a web application penetration test of for between and . Testing was manual and covered the scope set out in the written rules of engagement, measured against the OWASP Top 10:2025.

We reported findings: high, medium and low. A retest on confirmed the status of each reported finding, as listed in the retest summary.


ITECS

Redacted sample. Your letter names your application, test dates and results. Your auditor decides what evidence it accepts.

Choose the right test

Web app test, vulnerability scan or network test?

Each one answers a different question. Many companies need more than one, and it helps to know which question you’re asking first.

Web application penetration test compared with a vulnerability assessment and a network penetration test
Web application penetration testVulnerability assessmentNetwork penetration test
The question it answersCan someone misuse your application to read other users’ data, skip steps or take over accounts?Which known weaknesses exist across your systems, and which should you fix first?Can an attacker get from the internet, or from one foothold, to your critical systems?
How it worksManual testing of one application, signed-in and signed-out, against the OWASP Top 10.Finds and validates known weaknesses across an agreed scope, without proving attack paths.Controlled testing of networks and the paths between systems.
A good fit whenYou run a customer portal or SaaS product, or a SOC 2 audit or customer review asks for an application test.You need a baseline of known weaknesses and a ranked plan to fix them.You need to know what an attacker could reach on your internal and external networks.
How a vulnerability assessment worksNetwork, cloud and red team testing

From the report

What a finding looks like

Every finding follows the same format: what we found, the evidence, what it means for the business and how to fix it. Your developers can start on it without a meeting, and leadership can read the impact without the technical detail.

WEB-03A01:2025 Broken Access Control
High risk

Staff accounts can open the admin user list

Affected
User management pages and the users API of the demo application
What we found
The admin menu is hidden from Staff accounts, but the pages behind it are not protected. A Staff account that opens the admin address directly sees every user in the organization and can change their roles.
Evidence
Screenshots and a request log showing a Staff session loading the admin user list and saving a role change. Account names are redacted.
Business impact
Any staff member could give themselves admin rights or lock other users out. In a live system, that means access to every record the admin role can see.
How to fix it
  1. Check the user’s role on the server for every admin page and API call, not only in the menu.
  2. Return an access-denied error for admin requests from any other role, and log them.
  3. Add an automated test that calls each admin function as a non-admin user.
Retest
After the fix, a Staff account gets an access-denied error on every admin page and API call. Closed.
Sample finding written against an intentionally vulnerable demo application. It is not from a client test.

Web application penetration testing questions

Cost, scope, retests, SOC 2 evidence and how this test differs from a scan.

It’s a flat fee per application, starting at $6,990 for the Small tier. The tier is set by the size of the app: pages or screens, user roles and API endpoints, and Small, Medium and Large cover apps up to 150 pages, 6 roles and 150 endpoints. If your app goes past any limit of a tier, the test moves up a tier, and anything past Large gets a fixed-fee quote after the scoping call. You know the price before testing starts.

Yes. The test includes your application’s own API, up to the endpoint limit of your tier. If the API has no user interface of its own, like a partner or public API, our API penetration test is the better fit.

Each test covers one environment. We agree on it during the scoping call and write it into the rules of engagement, so everyone knows what we’ll touch before testing starts.

No. Source code review isn’t part of this test. We test the running application in one environment, the way an outside attacker or a signed-in user would see it.

The test doesn’t include remediation. Your developers get fix steps for every finding, and we retest the reported findings once within 90 days of the report.

One retest of the reported findings within 90 days of the report is included. More retest rounds, or a retest after 90 days, are quoted as a fixed fee.

Every test comes with a letter of attestation you can give your auditor or attach to a customer security questionnaire, alongside the full report. Your auditor decides what evidence it accepts, so tell us on the scoping call if a specific control or questionnaire is driving the test.

No. A scan lists known weaknesses automatically. In a penetration test, a tester tries to exploit them and looks for logic flaws a scanner can’t see, like one customer reading another customer’s records.

Yes, when it’s authorized. We test only what your written rules of engagement cover, in the environment and window they set.

Related testing

Testing an API, a mobile app or a network?

  • API penetration testing

    For APIs without a user interface, priced by endpoint count and tested against the OWASP API Security Top 10.

    API testing

  • Mobile app penetration testing

    An iOS or Android app and its backend API, tested to the OWASP MASVS.

    Mobile app testing

  • All penetration testing

    Network, cloud, wireless, social engineering and red team testing, plus continuous testing between engagements.

    Penetration testing services

  • Vulnerability assessment

    A ranked list of known weaknesses across your systems and a plan to fix them, without proving attack paths.

    Vulnerability assessments

Scope your web application test

Tell us about your application and we’ll confirm the tier on a scoping call.

Scope your testAll penetration testing