This desk audits your deployed web app with proof of consent. Below is every step, from request to receipt.
MANUAL · Contents
Enter the domain of the web app and an email for the result, then press “Request audit.” A unique token bound to that request is issued. Nothing is scanned yet at this point.
Place the issued token on your domain to prove ownership. Either method works. Being able to put it there is the proof.
Copy the token with the “Copy” button on screen.
Create the file /.well-known/star365-audit-consent.txt at your domain root, with the token as its only content.
When you open that URL in a browser and see the token as-is, you're ready.
On the DNS tab, copy the one-line record with the “Copy” button.
Add it as a TXT record in your DNS: name star365-audit-consent, value = the token.
DNS propagation can take minutes to tens of minutes. Verify once it has taken effect.
Use this if your static host can't serve a file path, or your site returns 200 for any address (soft-404). Copy the tag from the meta tab and put it inside the <head> of your homepage HTML.
The tag must be in the HTML the server sends — we can't see tags added later by JS. Tags outside <head> (in the body) don't count: on sites that render posts as raw HTML, someone else could plant one and forge consent.
contact=you@example.com: needed to get the receipt email at an address outside the domain (Gmail etc.); if you enter your email when requesting, it is pre-filled. badge=on: publishes the audit badge (off by default).Press “Verify consent” and the server reads the token location to verify it. Once verified, only that domain enters the allowlist and the audit queue. External audits use read-only GET requests only — no injection, brute force, or overload. There is exactly one exception: if the audited bundle ships a Supabase project URL (*.supabase.co) and anon key, we send read-only GETs to that one project host to test whether RLS is on. Only table names the bundle already calls, one row per table, and row values are neither read nor stored.
When the audit finishes, you receive the receipt by email. Each item's verdict is one of three values (failures carry a severity), kept in a tamper-evident hash chain:
20 checks observable from the outside with GET: reachability · secrets shipped in the browser bundle · open sensitive paths (27 of them: .env, .git, …) · security headers. Plus what only shows up when the page is actually opened in a browser — JS console errors, your own assets returning 4xx/5xx, http:// resources requested by an HTTPS page (mixed content), whether it deployed as a blank screen, horizontal overflow at 390px on mobile, and dead internal links. The browser sends GET only — even if your page fires a POST, it never leaves through us. What we cannot see from outside stays «undetermined». For apps that use Supabase, we also test RLS (when the bundle ships an anon key).
Only with an explicit request and granted access: file permissions, DB exposure and firewall, process privileges, dependency vulnerabilities. Any secrets found are kept as fingerprints only — originals are not stored.
We audit only domains whose consent is proven. Results go to you alone and are never published. We take no funds or payment methods; donations go straight to a wallet.
Once the audit is done you can put a “star365 audited” badge on your site. The badge appears only when you turn it on — add a line badge=on next to the token in your consent file (or TXT record). Until you do, the badge URL returns 404 and does not even reveal that you were audited. Only domains with a real receipt get a badge (it can't be forged), and failure counts are never shown publicly. Just replace the domain in the code below with yours:
<a href="https://audit.star365.site/?ref=badge"><img src="https://audit.star365.site/badge/YOUR-DOMAIN.svg" alt="Security audited by star365"></a>Done once, by a person: the command below prints the consent file content and a receipt key. Upload the file content (including the final standing=on line) to your site and store the printed NONCE and RECEIPT_KEY as CI secrets.
curl -fsSLO https://audit.star365.site/ci/star365-audit.sh && bash star365-audit.sh request YOUR-DOMAIN you@example.comThen add one step to your deploy pipeline (GitHub Actions example — keep action.yml and star365-audit.sh together in your repo; on other CIs run bash star365-audit.sh rescan):
- uses: ./.github/actions/star365-audit # action.yml + star365-audit.sh
with:
nonce: ${{ secrets.STAR365_NONCE }}
receipt-key: ${{ secrets.STAR365_RECEIPT_KEY }}
fail-on: critExit codes: 0 pass · 1 fail (by default only «critical» fails; fail-on: warn also fails on «warn») · 2 undetermined (timeout, no consent). A domain is audited at most once an hour. To stop recurring audits, remove the standing=on line — the next request is refused.
Check the file URL is exact (typos, case) and its content is only the token. For DNS, wait for propagation, then press “Verify consent” again.
No. It means we couldn't read that item; instead of hiding it as a pass, we tell you plainly. If needed, it can be resolved with the source location or an SSH internal audit.
Once consent is verified it enters the automatic queue, runs shortly, and the receipt is emailed when done.
External audits are free. SSH internal audits and continuous monitoring are arranged after a consultation, based on scope. If it helped, a voluntary (non-custodial) donation is welcome.
← Home / request an audit