Adversarial security for PR previews

Your PR preview gets an adversarial twin.

SakaForge intercepts your Preview/Staging deployment at pull-request time, registers two isolated users, attacks your changed endpoints like a real adversary — and reports only proven, reproducible access-control bugs with the fix included.

0%
false positives — findings require a 3-condition proof: HTTP 200, private-data evidence, double replay
< 180s
per run — delta scanning tests only the endpoints your PR actually touched
Fix PR
every verified finding ships with a suggested patch, validated against a copy of your app
sakaforge scan —url https://pr-42.preview.app.com
$ sakaforge scan --url https://pr-42.preview.app.com --fix
[1/5] deployment_status: success → scanning changed endpoints only
[2/5] dual-tenant recon: victim_saka@… / attacker_saka@… registered
[3/5] attacks: BOLA · BFLA · mass-assign · unauth · over-fetch · hidden routes
[4/5] proof: 3-condition check → 1 verified finding (0 false positives)
[5/5] repair: patch generated + verified → PR comment posted

Proof surface

Real output from our demo target

This is an actual alert produced by the SakaForge pipeline against a deliberately vulnerable demo application — reproducible cURL included, tokens redacted.

Foreign-target validation
Juice Shop: 3 / 3

All three enumerated vulnerable surfaces found with 0 false positives — BOLA basket read, BOLA address write, BFLA user list (24 accounts). OWASP Juice Shop v20.2.0, engine unchanged.

Foreign-target validation
crAPI: verified leak

Order details (email, phone, price) readable with no credentials at all — proven with the 3-condition check. Video surfaces probed and honestly recorded as fail-closed in this version; nothing was claimed without proof.

Control target
Polygon: 7 / 7

All 7 planted access-control bugs found — including a hidden route no UI links to (tree-sitter code recon) and an over-fetched password hash no cross-tenant attack can see. FP = 0.

Install the GitHub App

Preview deployments get scanned automatically after install.

Install on GitHub npm i @sakaforge/dev-auth

How it works

Four steps, no YAML, no babysitting

01

Preview hook

GitHub webhook catches deployment_status: success. The delta scanner maps your PR's changed files to the endpoints they touch.

02

Dual-tenant recon

Headless browser registers User A and User B, drives real UI flows, and records every entity and its CRUD endpoints.

03

Mutation attacks

BOLA token swaps, BFLA admin probes, mass-assignment injections, unauthenticated replays, over-fetch lexicon checks — plus tree-sitter code recon that attacks hidden routes the UI never links to.

04

Proof + fix PR

A bug counts only when it's proven three ways: 200, leaked private data, and a double replay. Verified patches ship with the report.

GitHub PR Runner
Preview URL · Git diff · <180s budget
Adversarial Twin
Dual-tenant sessions · mutation matrix · 0% FP proof
Repair Engine
AST context · verified patch · PR comment with PoC
Platform
Scan queue · forge credits · dashboard

Pricing

Start free. Scale when your team does.

Developer

Free
  • Up to 20 PRs / month
  • IDOR / BOLA detection
  • cURL PoC in the PR comment
  • 1 repository
Start free

SCALE

$499+/mo
  • Priority workers
  • SOC 2 compliance pack
  • Continuous audit mode
  • Unlimited repositories
Talk to us

Trust badge

Wear the shield on your README

One line of markdown tells contributors your previews are adversarially tested.

[![Secured by SakaForge](https://img.shields.io/badge/SakaForge-IDOR%20Protected-brightgreen)](https://sakaforge.art)

Early access

Be first in line

We're onboarding a small batch of teams every week. Leave your email and we'll get back to you with an invite.

FAQ

Questions, answered

Does it slow down my CI pipeline?

No. SakaForge runs on the preview deployment in parallel with your CI — never inside it. A hard 180-second budget and delta-only scanning keep it bounded.

How do you guarantee zero false positives?

A bug is reported only when three conditions hold at once: the request returns 200, the response leaks the victim's private data (or provably changes their state), and the exact attack replays twice with identical results.

What about apps behind Google OAuth or CAPTCHAs?

A mock-auth mode uses a signed override header on staging so the twin can act as two tenants without touching your real IdP. WAF bypass is done via a per-customer HMAC signature header.

Will the test users pollute my staging database?

No. Every run ends with an automatic teardown that deletes the entities it created, and calls to payment/SMS gateways are intercepted and mocked.

Which vulnerabilities does it catch?

Access-control logic bugs first: IDOR/BOLA (CWE-639), vertical privilege escalation (CWE-269), mass assignment (CWE-915), missing authentication (CWE-306) and excessive data exposure / over-fetching (CWE-213) — including endpoints hidden from the UI, found via source-code recon.