# Web and API audits

What a Boni audit covers across your app, identity, business logic and transport — and the written scope that has to exist first.

## What gets tested

An audit covers the surfaces that actually create customer risk — the ones automated scanners alone are bad at judging.

| Area | What is examined |
|---|---|
| Application surface | Websites, customer portals, admin panels, dashboards, staging hosts, API endpoints, exposed tooling |
| Identity and access | Authentication flows, session handling, authorization boundaries, password reset, token handling, role leakage |
| Common classes | Injection, cross-site scripting, SSRF indicators, access control, file handling, misconfiguration, sensitive data exposure |
| Business logic | Flows where the rules matter more than the payload, such as pricing, ordering, entitlement and payment paths |
| Transport and headers | TLS posture, HSTS, CSP, frame controls, cookie flags, CORS, cache behavior, public metadata hygiene |

Business logic is the part a scanner cannot do on its own, and it is usually where the expensive problems live.

## Before anything is tested

Active testing does not start without a **written target list** naming the surfaces in scope, the limits, and the timing. This is the one artifact an engagement cannot begin without.

| Agreed up front | Why it matters |
|---|---|
| Target list | A surface not on the list is not tested |
| Exclusions | Destructive actions and private-data access are excluded explicitly |
| Timing | Testing windows avoid your peak load and your release moments |
| Recipients | Who receives findings, and how they are delivered |

Staging hosts, forgotten subdomains and internal tools are worth putting *in* scope. They are frequently the weakest surface and the easiest to forget.

## What you get back

Each finding carries its evidence, a severity with the reasoning behind it, remediation guidance aimed at whoever has to implement it, and a retest position. The report has an executive summary that states the risk without losing the technical truth underneath.

Findings then move into the [vulnerability management loop](/security/vulnerability-management) rather than ending at the report — that is where retest and closure happen.

## After the fixes

Retest closes the loop. A fixed finding carries its retest evidence, so the closure is provable later — during a customer security review, a procurement questionnaire, or your next audit.

Canonical: https://docs.boni.one/security/web-app-audits
Version: 1
Updated: 2026-08-19T10:30:04.897Z