Launch-readiness checks often start with a harmless question: can an ordinary
visitor reach the action we expect? It is tempting to answer that by putting a
full browser, credentials, and a broad crawler into CI. That creates a much
larger security and privacy surface than the question requires.
I built Public-Path Evidence Check as a deliberately smaller alternative.
It accepts one to five explicit public HTTPS URLs and writes a private Markdown
report inside the GitHub-hosted runner. It performs GET requests only. It does
not execute JavaScript, follow redirects, retain cookies, submit forms, log in,
or upload the report.
The Action is free and open source:
The design constraint: observation, not interaction
The useful boundary is not “read-only browser automation.” A browser can still
send cookies, execute scripts, follow a redirect into a private service, or
trigger behavior during page load.
This Action instead captures a narrow set of facts from explicitly supplied
routes:
- the route requested;
- the final HTTP status;
- the reported content type;
- whether the bounded response looked like HTML; and
- a small set of visible-document signals suitable for a review worksheet.
The output is evidence, not a verdict. A 200 response does not prove that a
launch path is usable, accessible, compliant, secure, or likely to convert. It
only gives a reviewer a reproducible starting point.
A minimal workflow
name: Public path evidence
on:
workflow_dispatch:
permissions: {}
jobs:
inspect:
runs-on: ubuntu-latest
steps:
- uses: Allura-Gensin/public-path-evidence-audit-starter@af85ce58fa071c56e4d16d19b77c19a2a69dbd9e
id: evidence
with:
urls-json: '["https://example.com/", "https://example.com/pricing"]'
- name: Use the private report in this job
shell: bash
env:
REPORT_PATH: ${{ steps.evidence.outputs.report-path }}
run: test -s "$REPORT_PATH"
The example pins the reviewed commit rather than a moving tag. The Action
requests no repository permission and exposes the report path plus route and
HTML counts as outputs. It does not automatically upload an artifact because
publication should be an explicit caller decision.
The less-obvious safety work
Restricting the input to HTTPS is not enough. A CI runner can reach addresses
that should never become crawler targets, and DNS can change between
validation and connection.
The implementation therefore rejects:
- IP literals, credentials, fragments, query strings, and non-standard ports;
- private, loopback, link-local, multicast, documentation, benchmarking, and other special-purpose IPv4 and IPv6 ranges;
- hostnames with mixed public and non-public DNS answers;
- redirects; and
- self-hosted runners.
It resolves the hostname, caps the accepted address set, then verifies that the
connected peer is one of the approved public addresses. TLS still uses the
original hostname for SNI and certificate validation.
Resource limits matter as much as address validation. Each route receives one
15-second deadline covering DNS, connection, TLS, headers, and body. The whole
run is capped at 60 seconds. Responses stop at 1 MiB, and cumulative status-line
plus header bytes stop at 64 KiB. The report is created once under
$RUNNER_TEMP with private permissions; a pre-existing path is refused.
These limits do not make arbitrary network automation safe. They make this one
small public-observation task easier to reason about.
What the Action intentionally does not do
It does not:
- test forms, authentication, checkout, or account creation;
- make purchases or enter data;
- run a vulnerability scan;
- claim accessibility, privacy, SEO, performance, or compliance certification;
- infer conversion loss or revenue impact; or
- publish its report.
Those exclusions are product features. They keep a lightweight launch check
from silently expanding into production interaction or security testing.
A practical review loop
The repository includes CSV worksheets and a short checklist for the human
part of the review. A useful loop is:
- Name one visitor action.
- List no more than five public routes needed to reach it.
- Capture the bounded technical evidence.
- Review desktop and mobile presentation separately.
- Record observations apart from hypotheses and recommendations.
- Treat a clean path as a valid result; do not manufacture findings.
There is also a free browser-sized public-path checklist
for teams that do not want to add anything to CI.
I would welcome feedback on the boundary itself: which facts are valuable
enough to capture while keeping the Action credential-free, non-interactive,
and safe for a standard GitHub-hosted runner?
Disclosure: I used an AI coding assistant while implementing, testing, and
editing this project and article. I reviewed the resulting code, claims, and
published material.
Top comments (1)
Local processing is a product boundary, not just an implementation detail. If the browser owns the work, privacy claims become easier to inspect and failure modes become more predictable.