Report a vulnerability

Reporting

Email security@netguard.example. Include what you found, how to reproduce it, and what you think the impact is. If a proof of concept touches data that is not yours, stop at the point of demonstrating access rather than retrieving anything.

We will acknowledge within one working day and tell you what we intend to do within five.

What is in scope

• This website and its API.
• The resolver software, including the list distribution and its signatures.

What is not

• Findings from automated scanners with no demonstrated impact.
• Missing headers on endpoints that serve no content.
• Denial of service through volume.
• Social engineering of either of us.

Safe harbour

If you act in good faith, stay within scope, avoid privacy violations and data destruction, and give us reasonable time to fix the problem, we will not pursue any action against you. We do not currently pay bounties, and we will credit you by name if you want that.

What this site does

Not a complete list, but the parts a reporter usually wants to know.

• Passwords are salted and hashed with PBKDF2-HMAC-SHA-256 at 180,000 iterations, never stored or logged in any other form.
• Login is limited to five failures per account and address per fifteen minutes, and the response is identical whether or not the account exists.
• Sessions are opaque random identifiers in an HttpOnly, Secure, SameSite=Lax cookie, rotated on login and destroyed on logout.
• Every form and account-changing request carries a random double-submit CSRF token, compared in constant time, with the Origin header checked as well.
• State writes use atomic ETag preconditions, so concurrent requests cannot silently overwrite one another.
• Ownership is checked before every account-data mutation, so a guessed identifier returns nothing rather than changing someone else's record.
• Input is validated server-side against a schema, and only fields named in that schema are read from a submission.
• Output escaping is a property of the template engine, not something each page remembers to do.
• Content-Security-Policy allows scripts only from this origin with a per-response nonce; there is no unsafe-inline and no unsafe-eval.
• Request bodies are capped at 64 KiB and only two content types are parsed.
• There are no file uploads, because nothing here needs one.
• The deployed application has no third-party runtime package, native binding or runtime build step.

Reporting configuration

The machine-readable version of this page is at /.well-known/security.txt.