Skip to content
SKIDZ

Web Application Security Assessment

A web application assessment establishes what an attacker can do to your application and to the data behind it. We test the application and its supporting APIs from an unauthenticated position and from each role a user can hold, following OWASP methodology and extending it with manual analysis of business logic and authorisation boundaries that automated tooling does not reach.

Application Security Resilience — practice area

What the engagement covers

Black-box and white-box assessment against industry-standard methodology.

  • Authentication and session handling

    Login, multi-factor enrolment, password reset, and session lifecycle, assessed for bypass, fixation, and the ability to take over an account without its credentials.

  • Authorisation boundaries

    Every role and object the application exposes, tested for access that should not be permitted, including horizontal access between peer accounts and vertical access to administrative function.

  • Business logic

    The application's own rules — pricing, limits, workflow order, and state transitions — tested for sequences that produce an outcome the design did not intend.

  • Input handling and injection

    Input handling across the application and its APIs, covering injection into data stores, templates, and command interpreters, and the rendering paths that lead to script execution.

  • APIs and integrations

    The APIs the application depends on, tested directly rather than only through the interface, including undocumented endpoints and parameters the client never sends.

  • File handling and server-side requests

    Upload, parsing, and export paths, and any function that fetches a resource on the server's behalf.

How we do it

Scope is agreed in advance and documented in a statement of work before any work begins.

  1. 01

    Scope and access

    We agree the application, environments, and roles in scope, and you provide test accounts for each role. Where the engagement is white-box, source access is agreed at the same time.

  2. 02

    Manual testing against OWASP methodology

    Testing follows OWASP methodology for coverage and is driven manually, so business logic and authorisation flaws that automated scanning cannot recognise are found alongside the standard classes.

  3. 03

    Reporting

    Each finding is documented with a severity rating, the request sequence required to reproduce it, and remediation guidance written for the developers who will apply it.

What you receive

Written so findings can be assigned directly to the teams that will act on them.

  • Findings report

    Every finding with its severity rating, the request sequence required to reproduce it, and remediation guidance at code and configuration level.

  • Authorisation matrix

    The roles and objects tested and the access each combination permitted, so the gap between intended and actual permissions is visible in one place.

  • Remediation priority list

    Findings ordered by exploitability and by the sensitivity of what they expose, so the highest-value fixes are scheduled first.

Also in Application Security Resilience

Web, mobile, and delivery pipeline assessment across the development lifecycle.

Frequently asked questions

What is the difference between black-box and white-box testing?
Black-box testing works from the outside with no source access, in the position an external attacker holds. White-box testing adds the application's source code, which makes it possible to reach code paths that are hard to trigger through the interface and to state the precise cause of each finding. Both are offered, and which applies is agreed at scoping.
Do you test APIs as well as the user interface?
Yes. Supporting APIs are tested directly rather than only through the application that calls them, which surfaces undocumented endpoints, unused parameters, and authorisation checks that are enforced in the client but not on the server.
Will the assessment run against our production environment?
That is agreed at scoping. Testing against a staging environment that mirrors production avoids any risk to live data, provided the environment is current. Where production is the only accurate target, testing windows and excluded techniques are documented in the statement of work before work begins.

Scoping this engagement

Send us the systems in scope and the outcome you need. We will respond with a proposed scope, timeline, and commercial terms.

Request a proposal