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 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.