Security & Responsible Disclosure

Report a vulnerability

Send it to one address:

That mailbox is monitored on business days and routes to the people who can act on it. Please include, as far as you can:

• the affected URL, endpoint, or parameter;
• the vulnerability class, in whatever vocabulary you prefer;
• clear steps to reproduce it — a request and response pair, a curl command, or a short screen recording;
• what an attacker could actually achieve with it, which matters more to us than the CVSS score;
• any test accounts, IP addresses, or user agents you used, so we can tell your traffic from someone else's;
• how you would like to be credited, if you would.

Write in whatever language you are comfortable in. If you need to send something encrypted, say so in a first email and we will arrange a key exchange before you send the details. Please do not open a public issue or post the details anywhere until we have had a chance to fix it.

security.txt

The machine-readable version of this policy lives at /.well-known/security.txt, following RFC 9116. It carries the contact address, a link back to this page, our preferred languages, and an expiry date. If your tooling looks for that file, it will find it.

What is in scope

• This website and every page on it.
• The form-handling endpoints under /api/, including the quote request handler.
• /.well-known/ — the security contact and the Global Privacy Control resource — and the sitemap.
• Response headers and the site's security configuration — content security policy, transport security, caching, and anything that leaks more than it should.
• Form intake at /api/quote and /api/contact. Note that these validate a submission and then discard it — they send no email or SMS and trigger no downstream flow, so there is no delivery path to test.

Anything you can reach from this domain without breaking the rules below is fair game.

What is out of scope

Systems we do not control. Please do not test these, and report issues to their owners:

• Insurance carrier websites, portals, and rating systems.
• Our third-party client portal, agency management system, and other vendor products — tell us and we will relay it to the vendor.
• Our hosting, email, and SaaS providers' own infrastructure.
• Our social media profiles and third-party review listings.
• Employees' personal accounts and devices.

Findings we will acknowledge but not treat as vulnerabilities, unless you can show real impact:

• Missing security headers, cookie flags, or TLS configuration opinions with no demonstrated exploit.
• SPF, DKIM, DMARC, or DNS best-practice observations without a working spoof.
• Self-XSS, or anything that needs the victim to paste code into their own console.
• Clickjacking on pages with no state-changing action.
• Missing rate limiting, absent an amplification or resource-exhaustion path you can show.
• Denial of service, volumetric testing, and load testing of any kind.
• Social engineering, phishing, or pretexting against our staff or clients.
• Physical access to our office, and anything involving tailgating or dumpster diving.
• Reports generated wholesale by an automated scanner with no manual validation.
• Outdated library versions with no exploitable path in our deployment.
• Content or wording you disagree with — that is welcome feedback, just not to this address.

Rules of engagement

• Use your own data. Test against accounts and submissions you created. Never access, modify, or download data belonging to anyone else.
• Stop at proof. Once you have shown a vulnerability exists, stop. Do not pivot, escalate, or see how far it goes.
• Do not exfiltrate. If you stumble across personal information, stop immediately, do not save or share it, and tell us what you saw so we can assess the exposure.
• Do not degrade the service. No brute forcing, no flooding, no automated crawling at volume, and nothing that would make the site unavailable to a client trying to report a claim.
• Do not spam the forms. One test submission is enough. Mark it clearly as a test.
• Do not make it public first. Give us a chance to fix it before you write it up.
• Do not extort. A report that arrives with a payment demand, a deadline attached to a threat, or a withheld proof of concept is handled as an incident, not a disclosure.

Safe harbour

What happens after you report

• Acknowledgement within 3 business days. From a person, confirming we have your report and who is handling it.
• Triage within 10 business days. We reproduce it, assign a severity, and tell you what we concluded — including if we disagree with your assessment, and why.
• Progress updates at least every 14 days until it is closed, without you having to chase us.
• Remediation targets from the point we confirm the issue:

Disclosure. We are happy for you to publish once the issue is fixed, and we will coordinate timing with you. If a fix is taking us longer than 90 days, we will tell you why rather than go quiet, and we will not object to you publishing at that point.

If a vulnerability turns out to have exposed client information, we treat it as a security incident under our incident response plan and notify affected people and regulators within the deadlines the applicable state law sets. Our privacy policy describes how that works.

Recognition, not bounty

We are a 34-person insurance agency, not a technology company, and we do not run a paid bug bounty. There is no monetary reward, and we would rather say that up front than let you spend a weekend on it expecting one.

What we do offer: public credit in our release notes if you want it, a written thank-you you can point an employer at, and a straight answer about what we fixed and when. If you would rather stay anonymous, that is fine too.

How this site is built

Some context that may save you time, and which is verifiable from the page source:

• The site is mostly statically generated. Most routes are files; the exceptions are the two form-intake endpoints, which run in a Worker. No database sits behind any of it.
• It ships a strict Content Security Policy with no unsafe-inline or unsafe-eval.
• It loads no third-party runtime resources — no CDN scripts, font CDNs, icon kits, analytics beacons, or remote images — so it makes zero cross-origin requests. The three webfonts it does use are served from this origin under /fonts/, and font-src is 'self'.
• It sets no cookies and uses no client-side storage.
• It requires no JavaScript to function, including the quote form.
• The only endpoints that accept input are the form handlers under /api/.
• No payment card or bank account data is collected anywhere on this site.

Internally, the agency maintains the safeguards described in our privacy policy: encryption in transit and at rest, multi-factor authentication on every system holding client data, least-privilege access reviewed on role change, annual staff security training, and written incident response and business continuity plans.

If you are a client

This page is for security researchers. If you are a client and you think something has gone wrong with your information — a suspicious email that appears to come from us, a document you received that was not yours, or a sign that someone else has your portal credentials — do not use the disclosure address. Call us:

We will never email or text you asking for your password, a full Social Security number, or a bank account number. If a message claiming to be from us asks for any of those, it is not from us — forward it to security@greeneinsurance.example and then delete it.

Related: Privacy Policy · Terms of Use · Accessibility