Responsible disclosure policy

Version history

9 October 2026: added the list of deliberate design decisions that are not treated as vulnerabilities (section 4.3); restricted new testing authorizations to researchers with an established track record (section 5.1); set out what testing without authorization exposes the tester to (section 5.3).
18 September 2026: added client-side-only bypasses to out of scope (section 4.2).
1 September 2026: removed the designation of a data protection officer, replaced by a data protection contact.
29 August 2026: introduced the mandatory prior authorization requirement for all testing (section 5.1). Testing carried out before that date falls under the 4 June 2026 version.
4 June 2026: initial version.

1. Introduction

The security of the Brake Point platform, and of the telemetry data entrusted to it, is a priority. This policy describes how to report a vulnerability responsibly, what we commit to in return, and credits the researchers who have contributed to improving our security.

It applies to the following surfaces:

www.brakepoint.io (public marketing site)
app.brakepoint.io (web application)
api.brakepoint.io (REST API)
Brake Point iOS and Android applications

2. How to report a vulnerability

Before any testing, read section 5.1: all testing against our systems, automated or manual, requires prior written authorization, which is now granted only to researchers with an established track record. Reporting something you simply noticed requires none.

Send an email to security@brakepoint.io with the following:

Description of the vulnerability (type, OWASP class if relevant)
URL or endpoint affected
Reproduction steps (proof of concept, curl commands, screenshots)
Estimated impact (read/write, data accessible, authentication prerequisites)
Your contact info (name or pseudonym to credit, if applicable)

An RFC 9116 compliant /.well-known/security.txt file is also available.

3. Our commitments

Acknowledgement within 3 business days
Assessment and triage within 10 business days
Fix deployed within a window aligned with severity:
- Critical / High: 30 days
- Medium: 60 days
- Low: 90 days
Public credit on this page after the fix ships (anonymous credit available on request)
No legal action against researchers who follow this policy

4. Scope

4.1 In-scope

The categories below define what we accept as a report and what an authorization may cover. They are not an invitation to test.

Authentication, session, or access control vulnerabilities
Injections (SQL, NoSQL, command, template)
Cross-Site Scripting (XSS) with demonstrated JavaScript execution
Cross-Site Request Forgery (CSRF) on sensitive actions (password change, account deletion, billing changes)
Server-Side Request Forgery (SSRF), Local/Remote File Inclusion (LFI/RFI)
Insecure Direct Object References (IDOR) allowing access to another user's data
Exposure of secrets, API keys, or credentials
Privilege escalation (PILOT → TRAINER → ADMIN)
Bypass of Stripe payment flow or quota limits

4.2 Out-of-scope

Missing HTTP headers without a demonstrated exploit (CSP, HSTS, X-Frame-Options on their own: useful, but logged for internal hardening)
Self-XSS, clickjacking on public pages without a sensitive action
User enumeration on signup / login endpoints by design (BetterAuth returns the same status)
CSRF on non-sensitive actions (language toggle, logout)
Open redirects with no demonstrated impact
Email spoofing against subdomains with no MX
Vulnerabilities requiring physical access or compromise of the user's device
Denial of service (DoS, DDoS) attacks: do not attempt
Vulnerabilities in third-party dependencies with no demonstrated exploit on our infrastructure
Findings from automated scans without manual validation
Vulnerabilities already identified internally or already reported by a third party (duplicates)
Client-side-only bypasses with no server-side effect, for example modifying a response in your own browser to display admin pages whose APIs still refuse you
Send abuse of email, SMS or notifications: inbox flooding, exhausting a sending quota, repeatedly triggering a code send. This counts as denial of service and must not be attempted

4.3 Design decisions that are not vulnerabilities

A vulnerability is a behaviour that lets someone read, modify or destroy data that is not theirs, act with rights they were not granted, or degrade the service for others, and that you can demonstrate. A deviation from a checklist, a scanner rating or a "best practice", or a disagreement with a choice we made deliberately, is not a vulnerability on its own.

The behaviours below are deliberate. We know them, we chose them, and we do not treat them as vulnerabilities:

Role visible to the client: the role returned in the session response is used for display only. Every request is authorized on the server, from the role read in the database; changing that value in your browser grants you nothing
Public client code: everything shipped to the browser or to the mobile app is public by nature: route names, the code of admin screens, API paths, update bundles and manifests. Reading them is not an information leak
Rate limits: they are protective thresholds, not exact counters. Concurrent requests can exceed a threshold by a few units; that is not a bypass
Sessions: session lifetime, and the ability to hold several sessions at once on several devices, are product choices. Sessions are revoked on the server at sign-out and at password reset
Authentication policy: password composition rules, the absence of two-factor authentication, and the format and validity period of the codes sent by email
Security headers: the content of our headers, including the CSP directives required by the application framework, is chosen knowingly
CORS: the API accepts requests that carry no Origin header. CORS is a browser control, not an authentication mechanism; access to data depends on the session
Email authentication: the level of our SPF and DMARC policies

If you can demonstrate that one of these choices leads to a concrete impact as defined above, that impact is in scope and we want the report: describe the impact, not the choice. A report that only contests the choice is closed as informational, with a single reply. Severity is assessed by Brake Point; a CVSS score assigned by the reporter is not binding on us.

5. Rules of engagement

5.1 Prior authorization is required

Any testing activity against Brake Point systems requires prior written authorization, whether automated or manual. This covers authentication testing, access-control testing, rate-limit testing, the use of scanners, intercepting proxies or fuzzing tools, and the creation of any account intended for testing.

New authorizations are restricted. Close to 100 independent researchers have already tested the platform. That coverage is sufficient for a service of this size, and we no longer have the capacity to supervise every new request. Authorization requests are now considered only from researchers with an established, verifiable track record, for example: vulnerabilities credited in their name (CVE, vendor advisories), a public ranking on a recognized disclosure platform, published research, or an engagement on behalf of an identified security firm.

To request authorization, write to security@brakepoint.io stating:

your identity and contact details
the evidence of your track record (links to credited vulnerabilities, platform profile, publications, employer)
the intended scope (domains, endpoints, features)
the methods and tools you plan to use
your preferred testing window
the source IP addresses you will operate from

We respond within 5 business days to requests that establish such a record. A request that does not is declined and may not receive an individual reply. Authorization is granted in writing; it is personal, time-limited, restricted to the agreed scope, and revocable at any time.

Reporting is not testing. Reporting something you noticed during normal use of the service, without interacting with it to probe its security, requires no authorization and is welcome at any time at security@brakepoint.io.

Testing carried out without prior authorization falls outside this policy. Section 5.3 sets out what it exposes you to.

5.2 Conditions attached to a granted authorization

Under a granted authorization, researchers commit to:

Not disrupting the service nor degrading the experience of other users
Not accessing, modifying or deleting data that doesn't belong to you; use the test accounts agreed in the authorization
Not practicing social engineering against our employees, contractors or users
Not testing against Stripe, Brevo or Scaleway infrastructure beyond Brake Point's public endpoints
Not publicly disclosing the vulnerability before the fix ships (coordination required, 90 days default)
Staying within the scope, window and volume set by the authorization; absent an agreed volume, not exceeding 5 requests per second sustained
Reporting any accounts created for testing purposes, so that we can delete them

5.3 Testing without authorization

Brake Point does not consent to any security testing of its systems carried out without the prior written authorization described in section 5.1. Such testing is also prohibited by our Terms of Use (article 5.2).

Before you test without authorization, know the following:

The ground is already covered. Close to 100 researchers have already tested the platform. What a first pass turns up (rate-limit thresholds, the role visible to the client, header values, sign-up responses) is known to us and listed in sections 4.2 and 4.3: those reports are closed without credit
It earns nothing. We pay no bounty. Findings from unauthorized testing receive no reward and no public credit (section 6)
It is outside this policy. It carries none of the commitments in section 3, including the commitment not to take legal action
It is logged. Authentication requests, and access attempts refused for lack of rights, are recorded with their source IP address
Your account can be closed. Article 5.3 of the Terms of Use allows us to suspend or permanently terminate an account used for it
French criminal law applies wherever you are. Fraudulently accessing or remaining in all or part of an information system is punishable by up to three years' imprisonment and a fine of 100,000 euros (article 323-1 of the French Criminal Code), and hindering or distorting its operation by up to five years' imprisonment and a fine of 150,000 euros (article 323-2). The attempt carries the same penalties (article 323-7). An offence committed over an electronic communications network against a company whose registered office is in France is deemed committed in France (article 113-2-1)
We may act on it. We reserve the right to report unauthorized testing to the competent authorities and to claim compensation for any damage it causes

None of this applies to reporting something you noticed during normal use of the service, which remains welcome (section 5.1).

6. Rewards

Brake Point does not currently run a paid bug bounty program. We offer:

Public credit on this page (with link and vulnerability category)
Named acknowledgement in the fix commit and CHANGELOG
Brake Point swag (stickers, t-shirt) for notable contributions, on request, while supplies last
For exceptional contributions: extended free access to the Pro plan

Not eligible for public credit or the recognition above:

reports covering a vulnerability already identified internally before the report was received, or already reported by a third party
reports that are out of scope (section 4.2)
reports that only contest a documented design decision (section 4.3)
findings from testing carried out without prior authorization (section 5.1)
reports whose impact is not demonstrated

Eligibility is assessed by Brake Point. A report that is not eligible is still triaged and fixed within the timelines in section 3 where it is valid; only the recognition is withheld.

This policy may evolve into a paid program after the official launch (end of November 2026).

7. Acknowledgements

We publicly thank the following researchers for contributing to Brake Point's security:

Researcher	Vulnerability	Reported	Fixed
rae050	Privilege escalation	7 August 2026	10 August 2026

8. Contact

Vulnerability reports: security@brakepoint.io

Data protection contact: privacy@brakepoint.io

Postal address:

Ethan Consulting
10 allées des boutons d'or
78180 Montigny-le-Bretonneux
France