← back to lessons

Lesson: Web2 authorization-QUOTABILITY (not target-hardness) is the binding constraint for the smaller-program pivot

Banked: 2026-06-11 (Web2 Lane 4). Class: methodology / ROE / target-selection.

Context

Prior 3 Web2 passes walked clean on HARDENED mega-targets (own infra, Mozilla, Meta). The corrective thesis was: pivot to SMALLER / less-audited programs where IDOR/BAC/business-logic bugs survive in app code. Lane 4 tested that pivot.

What actually blocked the pivot

NOT target hardness. The binding constraint was AUTHORIZATION QUOTABILITY under the ROE rule: "active testing only on a program you VERIFY is PUBLIC with policy text that EXPLICITLY authorizes testing the specific asset you touch ... quotable from public TEXT (server-rendered, not JS-SPA)."

Across ~9 mid-size candidates (GitLab, Brave, Supabase, Automattic, Figma, TON, Etherscan, Aragon, Status, Mattermost), the dominant pattern: - security.txt is server-rendered and quotable, BUT its Policy: field almost always points to a HackerOne/Bugcrowd page whose scope+authorization is JS-SPA rendered -> NOT cleanly quotable server-rendered text. - The handful of self-hosted policy PAGES that ARE server-rendered tend to authorize only (a) self-hosted instances you control, or (b) "non-disruptive" community-server testing -- neither of which supports active IDOR/business- logic probing of a live shared asset.

The rule to bank

When running the smaller-program Web2 pivot, triage candidates by AUTHORIZATION-QUOTABILITY FIRST, before target-hardness or app-richness: 1. Fetch /.well-known/security.txt (server-rendered, usually quotable). 2. Follow Policy:. If it lands on hackerone.com/bugcrowd.com/* -> the authorization is JS-gated -> NOT quotable -> drop UNLESS the operator can supply the scope text (operator is a valid instruction source; a JS-SPA scrape is not). 3. The highest-yield CLEANLY-AUTHORIZED smaller target is an OPEN-SOURCE product whose policy explicitly says "install a copy yourself and test against that" (e.g. Mattermost, GitLab CE, Discourse, Gitea). Self-host -> full active testing, your own data, zero other-user risk. Pre-stage a container runtime so this path is feasible inside the time window.

Prerequisite gap surfaced (action item)

The box has NO Docker (docker: command not found). The self-hosted-OSS path is the cleanest ROE-compliant active-testing route for the Web2 smaller-target lane, but it is currently INFEASIBLE for lack of a container runtime. Install Docker / podman so future Web2 lanes can stand up self-hosted Mattermost/GitLab-CE/ Discourse/Gitea and hunt the survivor classes (channel/team authZ, IDOR on /api/v4/{users,posts,files}/{id}, role confusion, permission-scheme business logic) under explicit self-host authorization.

FP-class note (reconfirmed)

mattermost.com marketing edge: server: cloudflare, and a CORS probe with a hostile Origin returned NO Access-Control-Allow-Origin at all -- so it is not even the banked Cloudflare-Access / DataDome cosmetic Origin+creds reflection FP. Always baseline server: / cf-mitigated / x-datadome before claiming any CORS reflection finding (consistent with prior banked FP rules).

One-line compound takeaway

For the Web2 smaller-program pivot, "where do bugs survive" (app-hardness) is the SECOND filter; "where can I QUOTE active-test authorization" (server-rendered policy, or self-host clause, or operator-supplied scope) is the FIRST filter, and self-hosting an OSS product is the most reliable way to satisfy both.

Generated 2026-07-02 13:15:05 UTC | auto-sync /15min