Vulnerability disclosure policy

This policy applies to the Breeze service at breeze.pm and its subdomains, operated by Template OÜ, registry code 14110689, Tornimäe tn 7-79, 10145 Tallinn, Estonia. It is the policy referenced by our security.txt.

How to report

Email security@breeze.pm with "Security" in the subject line. A useful report contains:

• A clear description of the issue and why it matters.
• Exact steps to reproduce it - URLs, parameters, the accounts you used, and roughly when you tested.
• Evidence: a request and response pair, a short screen recording, or a proof of concept.
• Your assessment of the impact - what an attacker actually gains.

One issue per report, in English. We will acknowledge within five business days, tell you what we find, and fix on a timeline set by the risk. If we disagree that something is a vulnerability, we will say so and explain why rather than going quiet.

Rules of engagement

Test only against accounts and data that belong to you. You must not:

• Access, modify or retain another customer's data. If you reach someone else's data by accident, stop immediately, tell us, and delete anything you retrieved.
• Run automated scanners, fuzzers or crawlers against our production systems.
• Perform denial of service, load, stress or resource-exhaustion testing.
• Attempt social engineering or phishing of our staff, our customers or our suppliers.
• Attempt physical access to our premises or those of our providers.
• Pivot further into our systems than is needed to demonstrate the issue, install persistence, or degrade the service.
• Disclose the issue publicly before we have had a reasonable opportunity to fix it.

Stop as soon as you have confirmed the issue exists. You do not need to prove how far it goes.

Safe harbour

If you follow this policy in good faith, we will treat your research as authorised, we will not pursue legal action against you for it, and we will not support action brought by others on our behalf. This does not extend to conduct outside this policy, and it cannot waive the rights of third parties - our infrastructure providers and our customers are not bound by it, so do not test against their systems or data.

We do not pay for reports

Breeze does not operate a bug bounty programme. We do not pay a bounty, a fee, a finder's commission, swag or a gift card for a vulnerability report, and that does not change with the severity of the finding. Please decide whether to report on that basis before you spend time on it.

• Unsolicited invoices are disregarded and not answered.
• We will not sign a non-disclosure agreement, engagement letter, contract or vendor form as a condition of receiving a report.
• We do not buy security audits, penetration tests, compliance reviews or remediation services from people who approach us with unsolicited findings.
• We will not complete security questionnaires as part of a vulnerability report.

Making disclosure conditional on payment is extortion, not security research. We do not negotiate with such messages. They are retained, and reported to the relevant authorities and to the platform the sender used to contact us. The same applies to attempts to force a response by threatening publication, by contacting our customers, or by filing complaints with regulators.

Out of scope

The following are reported to us constantly and are almost never exploitable. We will close them without further discussion unless you include a working exploit against our production service, showing concrete impact:

Configuration opinions

• Missing or "weak" HTTP security headers - Content-Security-Policy, X-Frame-Options, Referrer-Policy, Permissions-Policy, X-Content-Type-Options, HSTS preload status.
• SPF, DKIM or DMARC record configuration, and email spoofing demonstrated only against your own inbox.
• TLS version or cipher-suite preferences, and support for older protocol versions.
• Missing DNSSEC, CAA or other DNS records.
• Cookie flags - HttpOnly, Secure, SameSite - on cookies that carry no sensitive value.
• Missing fields in our security.txt, or the absence of a bug bounty programme.
• Software version banners, directory listings and error pages that disclose nothing sensitive.

Tool output

• Any report consisting of automated scanner, SAST, DAST or AI-generated output that you have not reproduced and verified yourself.
• "Vulnerable dependency" findings inferred from a version string, without a working exploit against our deployment.
• Scanner grades and compliance-checklist output - "your site scores C on this tool" is not a vulnerability report.

Low or no impact

• Self-XSS, or anything that requires the victim to paste content into a developer console.
• Clickjacking on pages with no sensitive, state-changing action.
• User or email enumeration, including timing or wording differences in sign-in, sign-up and password-reset responses.
• Missing rate limiting or account lockout, absent a demonstrated concrete impact.
• Content spoofing or text injection with no HTML or script execution.
• Issues that require a compromised, rooted or jailbroken device, or physical access to an unlocked session.
• Issues affecting only end-of-life or unsupported browsers.
• Content that is public because a customer chose to publish it. Public projects, reports and forms are a feature.

Not ours, or not accepted

• Vulnerabilities in third-party services we do not control. Report those to the provider concerned; our providers are listed in Annex III of our data processing agreement.
• Denial of service, volumetric attacks and resource exhaustion.
• Social engineering, phishing, and physical attacks.
• Reports about a domain or host that is not ours.

What we do want

If it is not listed above and you can show real impact on the confidentiality, integrity or availability of customer data, we want to hear from you. Authentication and authorisation flaws, failures of tenant isolation, injection of any kind, server-side request forgery, and anything that lets one customer reach another customer's data are always in scope and always taken seriously. So is anything affecting our OAuth implementation or the MCP connector.

Credit

Once an issue is fixed we are glad to credit you publicly, by name or by handle, if that is what you want. Tell us how you would like to be named. We will not name you without asking.

See also our security overview, privacy policy, data processing agreement and terms of service.

Last revised: August 18, 2026