BASEER

SPEC Coverage specification

What we test

The full surface of a Baseer test — what we cover, what we deliberately don't, and the ten attack types we put your web app through. Every finding is proven, never a guess.

Scope
Web application
Coverage
Certified-10
Evidence
Proof by execution
Price
$20 · launch pricing

§01

Scope — the thing that actually gets startups breached.

We test your web application: the site, the API behind it, and the data those reach. Not the raw infrastructure underneath. That focus is deliberate — for a startup, the breach almost always comes through the app itself.

In scope

  • Login, sign-up, password reset
  • Forms, checkout, file uploads
  • The API behind the app
  • The data those reach
  • Access between one customer and another
  • Exposed pages, files and secrets

Out of scope

  • Network ports and firewalls
  • The operating system
  • Cloud-account configuration

A different kind of test. An honest boundary is a feature, not a gap.

§02

Your app is three layers. An attacker moves through all of them.

Most people picture a website as the page they can see. The break-ins that hurt happen underneath it — so we test the whole depth, the way someone getting in would.

  1. The surface

    What customers see and touch — pages, forms, logins, checkout. The front door and every window.

  2. The logic

    The API and the code behind the page — the machinery that decides who may do what. Most damaging flaws live here, out of sight.

  3. The data

    Accounts, orders, records — what an attacker is actually after. We test whether the first two layers can be made to give it up.

§03

The Certified-10 — the coverage matrix.

Ten high-impact attack types, run on every test. Each is a question about your app; for each, we try to make it happen and only record it if we actually could.

# Attack type What an attacker could do Covered
Getting in The ways in that don't need a break-in at all.
01 Authentication & SessionAuth Can someone get in as a user they're not? An attacker slips past the login, keeps a session alive after sign-out, or walks in on a password left at its default. covered on every test
02 Exposure & MisconfigExposure Is anything left open that should be shut? Exposed admin panels, debug pages, default passwords or leaked files hand an attacker a head start before they've done any real work. covered on every test
Turning your own logic against you Where your app's own machinery gets pointed the wrong way.
03 Broken Access ControlIDOR Can one customer reach another customer's data? An attacker changes a single number in a link and sees orders, profiles or documents that were never theirs — no break-in required. covered on every test
04 SQL InjectionSQLi Can someone trick your database into handing over data it shouldn't? An attacker reads — or changes — records straight out of your database: accounts, orders, anything you store, reached through a single input field. covered on every test
05 Server-Side Request ForgerySSRF Can your app be made to fetch things it shouldn't? An attacker makes your own server reach internal systems that were never meant to face the internet. covered on every test
06 Command Injection / RCERCE Can someone run commands on your server? An attacker makes your app hand them control of the machine itself — reading secrets, or running anything they like on the host. covered on every test
Weaponising what you accept When the things you let users send become the attack.
07 Cross-Site ScriptingXSS Can one visitor run code inside another visitor's session? An attacker takes over a logged-in customer's session from a page they both use — acting as them, seeing what they see. covered on every test
08 Server-Side Template InjectionSSTI Can a template be made to do more than render? An attacker reaches into your template engine and runs expressions that were never meant to be evaluated, from inside your own pages. covered on every test
09 Path Traversal / LFIPath Trav. Can a file path escape its folder? An attacker walks a file path out of the directory it was meant to stay in, reading internal files they were never meant to see. covered on every test
10 File UploadUpload Can an upload become a way in? An attacker uploads something that isn't the file it claims to be, and turns your upload feature into a foothold. covered on every test

§04

How a test runs — prove it, fix it, verify it.

  1. 01 · Prove

    We don't flag maybes. We attempt the attack and capture what happened — so a finding is something we did, with evidence you can reproduce.

  2. 02 · Fix

    Every proven finding comes with a clear fix your developer can act on — a next step, not a lecture. We never touch your code.

  3. 03 · Verify

    After you ship the fix, we run the same attack again. The proof it's closed is that it now fails — dated, and re-runnable. The loop isn't done until it holds.

§05

If we can't demonstrate it, it isn't in your report.

That is the whole difference. A scanner hands you a wall of "possible" issues and leaves the triage to you. We record only what we actually pulled off — which means zero false positives, and a report you can forward without checking it yourself.

See what a real report looks like

§06

Safe by design — and only ever with your say-so.

  • You prove you own it first. Before we touch anything, you add a small DNS record — the same one-minute check Google uses. No proof, no test.
  • Nothing destructive. Rate-limited, non-destructive, using our own test data — never yours, never anything that changes your live system.
  • Your data stays yours. Your report and its evidence are yours to keep and share — or not.

Find out what an attacker can actually reach.

Test your app — $20