Report a vulnerability
If you have found a security problem here, we want to hear about it, and you will not be treated as an adversary for telling us.
Machine-readable version: /.well-known/security.txt (RFC 9116). Effective 2026-10-15.
How to report
Use the contact form, and say in the first line that it is a
security report so it is not read as an enquiry. RFC 9116 accepts a web address as the
contact point, so that form is what security.txt names.
A useful report says what you found, on which URL, and the steps to reproduce it. A single request or a short screen recording is worth more than a scanner export.
What is in scope
sechb.comandwww.sechb.com, and the static files served from them.- The HTTP response headers, TLS configuration and DNS records for those two names.
What is out of scope
- Any other host under this domain. Subdomains other than the two named above are not covered by this policy or its safe harbour.
- Denial of service, load or stress testing, and traffic volume that degrades the host.
- Social engineering, phishing or physical attempts against us or anyone else.
- Automated scanning at volume. This is one small static site; read it by hand.
- Reports produced only by a scanner, with no demonstrated impact.
- Findings that assert a missing header or a TLS setting without showing what it lets an attacker do. Best-practice observations are welcome, but they are not vulnerabilities.
Safe harbour
If you make a good-faith effort to follow this policy, we will not pursue or support a legal claim against you for your research, and we will say so in writing if you need it. Good faith means: stay within the scope above, stop as soon as you have confirmed a problem, do not access, alter or retain anyone else’s data, and give us a reasonable chance to fix it before you publish.
This safe harbour is given by SecHB and covers only SecHB’s own claims. It does not bind the hosting provider, the registrar or any other third party, and it does not cover activity outside the scope above.
What happens next
- Acknowledgement within three business days.
- An assessment, and a fix or an explanation of why it is not one, within thirty days.
- Credit on request when a report leads to a change. We will not name you without asking.
There is no bug bounty and no payment.
/theme.js, which
remembers your light/dark choice and does nothing else; /analytics.js, which decides
whether a page view is counted and, only then, loads /count.js, the unmodified script of
GoatCounter, the open-source page counter we run on this server (the
privacy page says what it keeps); and /contact.js,
which loads on the contact page alone and helps the server tell genuine enquiries from automated
ones. Those four files are the only scripts this site serves. The Content-Security-Policy, in full, is
default-src 'none'; script-src 'self'; connect-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; base-uri 'none'; form-action 'self'; frame-ancestors 'none': no inline script runs, and neither a script nor a request may
reach any other origin. On the server, the contact form posts to a small handler written
against the standard library alone — it binds to localhost, keeps a minimized record of each
submission in a local SQLite database so that automated spam can be told from real enquiries (the
privacy page lists every field of that record and how long each one lives), and runs under a systemd
confinement that denies it every capability and every network address but the loopback interface,
where the mail service and the name resolver it uses both live. The page counter, GoatCounter, runs
as a separate unprivileged service under a similar confinement and with no network of its own: it
listens inside a private network namespace, which only the web server can reach, through a local
socket. The web server passes it the one public address /stats/count, and its figures
are reachable only behind our internal login. Naming all of it is more useful to
you than claiming there is none.