Website, Web App and API Security Assessment Cost

Why is there no universal price for every website?

A brochure website with a few public forms is fundamentally different from a web application with sign-in, several roles, payments, file uploads and partner APIs. One domain may contain many states, permission boundaries and high-consequence actions. Pricing by page count or a fixed scanner package therefore says little about the work required to verify risk.

OWASP ASVS provides verifiable requirements that can help define coverage and rigour, while the OWASP WSTG provides testing approaches across application functions. They give buyer and reviewer a common language, but the final scope still needs to reflect the actual architecture, data, roles and business objective.

• ✓Domains, applications, APIs and environments authorised for review.
• ✓User roles, account types and permission boundaries to compare.
• ✓High-consequence flows such as payment, privilege changes, uploads and data exports.
• ✓Testing windows, operational coordination and impact constraints.

A useful security proposal does not sell a vulnerability count. It defines the evidence needed for the engineering team to know what to fix first.

Six work areas that determine assessment cost

The first area is discovery and scoping: inventory assets, review documentation, identify sensitive data, prepare test accounts and agree rules of engagement. Next comes mapping the application, authentication, sessions, authorisation, data-entry points, dependencies and observable configuration. Good preparation directs testing time towards important hypotheses rather than rediscovering basic information.

The review then combines technical examination, controlled low-impact checks and validation of findings. Cost also includes impact analysis, reproducible evidence, remediation guidance, an engineering walkthrough and retesting. NIST SP 800-115 treats planning, test execution, analysis and mitigation strategy as parts of a complete assessment process; a scanner export is not the whole engagement.

• ✓01. Discovery, assets, objectives and testing limits.
• ✓02. Mapping the observable architecture and attack surface.
• ✓03. Reviewing authentication, authorisation, input, configuration and business flows.
• ✓04. Validating findings to remove false positives and preserve minimal evidence.
• ✓05. Reporting, prioritisation, remediation guidance and engineering walkthrough.
• ✓06. Retesting agreed changes and recording residual risk.

What must a credible security proposal state?

The proposal should list in-scope and out-of-scope assets, accounts supplied, the test window, environment, prohibited actions and the contact who can stop testing if service impact appears. It should distinguish automated scanning, configuration review, manual checks and exploit validation. A broad label without the actual activities leaves buyer and provider expecting different depths.

Deliverables should describe the risk method, evidence format, executive summary, developer detail, walkthroughs and retest allowance. Ask who owns test data, how long evidence is retained and how sensitive information is handled. Those details protect both the organisation and the review team.

• ✓Domains, APIs, roles and priority functions.
• ✓Rules of engagement, testing window and emergency stop channel.
• ✓Method, reference standards and explicit exclusions.
• ✓Report, walkthrough, retest, evidence retention and deletion.

Control cost without weakening the evidence

A company can shorten discovery by preparing an inventory, flow diagrams, endpoint lists, role matrix and working test accounts. Select a stable release, close known defects and nominate an engineer who can answer questions promptly. When budget is limited, prioritise assets holding important data and flows that can change money, privileges or business state.

Do not save money by removing validation or retesting. A long list of false positives consumes more engineering time than the initial saving. A narrow scope with a baseline, negative controls, reproducible evidence and remediation order usually creates more value than broad scanner-only coverage.

• ✓Provide two or more accounts to test permissions across roles and objects.
• ✓Supply test data and a safe way to restore state.
• ✓Prioritise important flows instead of treating every screen equally.
• ✓Group fixes into a planned retest rather than handling them ad hoc.

When does a security review fit, and when is an independent penetration test needed?

A security review fits before launch, after a major authentication or authorisation change, when an unreviewed web app needs a baseline, or when developers need a contextual remediation backlog. Low-impact scope can also be a sensible first step for a sensitive production system.

If a contract, customer or compliance obligation requires an independent penetration-test report, or the objective includes deep exploit validation, infrastructure testing, social engineering or a Red Team exercise, use a provider with the appropriate capability, legal coverage and rules of engagement. Friday Works currently publishes a scoped website, web app and API security assessment, not a full penetration-testing or Red Team programme.