Security notes

What I can prove

Security is the easiest thing to claim and the hardest to demonstrate. So this page lists what I actually tested, what I hardened, and what I am still learning — with the commands to check it yourself.

Tested
Hardened
Learning

Tested

Checks I can reproduce on systems I am allowed to touch.

This site is a static export: no server code, no database, no forms, no cookies. There is no session or injection surface to speak of.
Dependencies: bun audit reports 0 known vulnerabilities across 103 packages.
No third-party scripts or CDNs. Fonts are self-hosted, there is no analytics and no external font API.
Every external link opens with rel="noreferrer".
No secrets tracked: .env* is ignored and the repository contains no keys.
PipeDuck config parser: malformed lines are rejected with the line number, and numeric thresholds are clamped instead of trusted.

Hardened

The defaults around the code, not just the code.

main is protected: every change requires review and the required checks, enforced for the owner too.
Two required checks: build, plus a policy check that every change closes a real issue.
The workflow token declares contents: read; Pages deployment adds pages: write and id-token: write.
No collaborators and no pending invitations. Force-push and branch deletion are blocked.
Linear history only: squash or rebase, no merge commits.

Learning

Stated plainly, because pretending otherwise would be a lie.

CTFs: ongoing practice. One public training lab below; more write-ups to come.
Bug bounty: just started. No accepted reports yet.
No security certifications. I do not sell penetration tests.
Training lab: BOLA/IDOR in a local invoicing API — reproduce, impact, fix and regression test.

Public proof / training lab

BOLA/IDOR in an invoicing API

Authentication works; object-level authorization does not. A local, synthetic API reproduces another tenant's invoice, then fixes it and proves both states with a regression test. Deliberately vulnerable, loopback only, not a client engagement.

Training exercise, not a real-world CVE.

Read the lab

Threat model

What could go wrong in the two things I maintain, and the current status of each mitigation.

This siteDefacement through the repositoryVerifiedProtected main, required checks, contents: read token, no collaborators.

This siteThird-party code injected at build timeVerifiedLockfile-pinned dependencies, zero known vulnerabilities, no external scripts.

This siteMissing browser security headersOpenGitHub Pages does not allow custom headers: no CSP, no X-Frame-Options. On a custom host I would set them.

PipeDuckMalformed or hostile values in the config fileVerifiedThe parser rejects bad lines with line numbers and clamps percentages and thresholds; covered by config tests.

PipeDuckAudio lost when ducking stops or the sink failsVerifiedThe virtual sink has an abandon path as a fallback, and restore failures are tested.

PipeDuckTray and D-Bus surfaceOpenNot threat-modeled yet. Next item on the list.

Check it yourself

The same three commands I ran, with the output I got.

$ bun audit
No vulnerabilities found (checked 103 packages)
$ curl -sI https://errusso.github.io
strict-transport-security present · no content-security-policy (GitHub Pages)
$ git ls-files | grep -i env
(no output — no environment files tracked)

What this page is not

It is not a pentest portfolio. I have not been paid to break into anyone's system, and I will not claim I have. The lab is a deliberately vulnerable local exercise, not a client finding. Everything above is either verifiable in this repository or explicitly marked as learning.