Vulnerability Disclosure Policy

Esta política também está disponível emportuguês.

1. The 30-second summary

• Found a flaw? Send it to security@borai.app.br with reproducible steps. Portuguese is preferred, English is fully accepted — see section 6.
• As long as you follow this policy, your research is authorised by us. We will not sue you or report you to the authorities over it.
• We pay no monetary rewards. We offer public credit in the Hall of Fame, a named mention in our security posts and a verifiable certificate stating the level of your finding.
• No DoS, no load testing, no spam, no social engineering, no touching other people's data.
• A report without a manual proof of concept will not be triaged.

2. Scope: what may be tested

The targets below are operated by Borai and are covered by this policy. Anything outside this list is not authorised.

Out of scope, no exceptions:

• Third-party services we use: hosting provider, CDN, payment gateway, e-mail provider, forms, analytics and feedback platform. Flaws in those products belong to their vendors, not to us. If the flaw is in our configuration of those services, it is in scope.
• Accounts, devices and data belonging to anyone other than you.
• Offices, employees, contractors and physical infrastructure.
• Any domain or profile not listed in the table above, including the brand's social media accounts.

3. What interests us most

We prioritise by real business impact. These are the findings that make our triage drop everything:

• Ticket validation flaws: forging, duplicating or replaying a QR code, or making the gate accept an invalid ticket.
• Financial manipulation: altering price, ticket batch, comp tickets, fees, affiliate commission or excursion payouts.
• Broken authorisation (IDOR): reading or altering another organiser's event, sales, attendee list or reports.
• Privilege escalation: attendee to promoter, promoter to organiser, organiser to administrator.
• Account takeover: flaws in password recovery, OTP, sessions, tokens or social login.
• Personal data exposure: access to data of attendees, freelancers, certificates or photo albums beyond the intended permissions.
• Injection and execution: SQL/NoSQL, command, template, deserialisation, SSRF, RCE.
• Leaked secrets: live API keys, tokens or credentials in public repositories, bundles, HTTP responses or build history.
• Proven subdomain takeover.

4. Rules of engagement

Always:

• Use only accounts you created yourself. Prefix the name with pentest- to make our triage easier.
• Identify your traffic by sending the X-Bug-Bounty: your-handle header with your requests. This separates research from attack in our logs and keeps you from being blocked.
• Stop the moment you have confirmed the flaw. One record, one row or a partial screenshot already proves access. Do not pivot, do not escalate beyond what is needed, do not go digging.
• Keep destructive testing, fuzzing and injection in the beta environment.

Never:

• Denial of service and social engineering, the two absolute prohibitions detailed just below.
• Aggressive automation. Stay under 5 requests per second, and no mass directory or parameter scanning against production.
• Access, download, copy, alter or delete data that is not yours. If access to someone else's data is the bug, see section 9.
• Delete or corrupt data, accounts or events. If you need to write something, write it to your own, clearly marked record.
• Send e-mail, SMS or notifications to other people's addresses and numbers.
• Install backdoors, maintain persistence, or leave anything running after the test.
• Make the flaw public before what is agreed in section 11.
• Condition the disclosure of details on payment. A report of that kind leaves the programme and is treated as an extortion incident.

5. What does not qualify

We close the items below without triage. It is not rudeness: we are a small team, and every generic report delays the fix of a finding that matters.

• Raw automated scanner output, with no manual proof of concept and no demonstrated impact.
• Missing security headers with no concrete exploitation.
• SPF, DKIM or DMARC configuration, without a forged e-mail that actually lands in an inbox.
• Self-XSS, or XSS that requires the victim to paste code into the console.
• CSRF on actions with no impact, such as logout, theme switching or list sign-up.
• Clickjacking on pages with no sensitive action.
• User or e-mail enumeration, with no further demonstrated impact.
• Missing rate limiting, with no concrete, successful exploitation.
• Software version disclosure, server banners, public metadata files.
• Cookie flags on non-sensitive cookies.
• Flaws requiring an unsupported browser, a rooted or jailbroken device, or physical access to the victim's unlocked phone.
• Social engineering, physical attacks, and any form of denial of service.
• "Best practice" reports with no associated risk.
• Disagreement with business rules, pricing, refund policy or site content.
• Flaws already known to us or already reported by someone else. First valid submission wins.

6. How to report

Send one report per vulnerability to security@borai.app.br, containing:

1. A clear title and your severity estimate, with a CVSS 3.1 vector if you use one.
2. The exact URL, endpoint and parameter, and which environment you tested.
3. Reproducible steps, performed manually.
4. Proof of concept: request and response, screenshot or a short video. Without a reproducible PoC, the report is closed.
5. Real-world impact: what an attacker can actually do with this.
6. A suggested fix, if you have one. Optional and always welcome.
7. How you want to be credited: name, nickname, handle, profile link — or anonymous.

Do not attach third-party personal data you may have found. Describe what you saw, give an estimate of the volume and, if you need to prove it, send a single record with the sensitive fields redacted.

Report language

Write in Portuguese whenever you can. Our team is Brazilian, and a report in Portuguese is read, understood and triaged faster, with nothing lost in translation — especially for business-logic flaws, where nuance matters.

When that is not possible, write in English. We accept English reports in full, with no penalty whatsoever to handling, timelines or recognition. This policy is also published in Portuguese.

We never reject a report because of its language, and please do not run it through machine translation if that hurts technical clarity — plain English beats confusing Portuguese.

7. Our response times

How we classify severity

Severity sets the remediation deadline and is the level printed on your certificate. We use CVSS 3.1 as a reference, but the final call is ours and weighs impact in Borai's context: tickets, money and attendee data count for more than theoretical severity.

If you disagree with the classification, argue your case. We reclassify often when a researcher demonstrates an exploitation path we had not seen, and the certificate is reissued with the corrected level.

Timelines

Borai is run by a small team. We would rather publish a generous deadline and meet it than publish a flattering one and miss it. The timelines below are in Brasília time:

If we are going to miss a deadline, we tell you before we miss it, with the reason and the new date. A critical flaw in production jumps the queue: those are handled as an emergency and you get updates every few days, regardless of the table.

Security changelog: we publish in aggregate

Every six months we publish a public security summary. It is deliberately aggregated, in the form "this period we received X valid reports, Y of them authorisation and Z data exposure, with an average time to fix of N days".

We do not publish endpoints, parameters, payloads, vulnerable versions, or any technical description that would allow someone to reproduce a flaw or hunt for variants of it. This is not a lack of transparency: publishing a detailed map of every fix hands attack surface to people who never reported anything, and adds nothing for the person who did. The technical detail stays between you and us, and can go public in the write-up you yourself publish, under the terms of section 11.

8. Safe harbor

This is the most important section of the document for you.

As long as you follow this policy, Borai considers your research expressly authorised activity. On that basis we commit to:

• not initiating civil action or criminal complaint against you over the research;
• not reporting your activity to the authorities as unauthorised access;
• stating in writing, publicly if needed, that the activity was authorised, should a third party question or take action against you over it;
• not treating testing carried out under these rules as a breach of our Terms of Use.

This authorisation matters because article 154-A of the Brazilian Penal Code, introduced by Law 12,737/2012 and amended by Law 14,155/2021, criminalises intrusion into a computer device precisely when it happens without the express or tacit authorisation of whoever operates it. This policy is that express authorisation, and it applies only:

• to the targets listed in section 2;
• to the actions permitted in section 4;
• to those who report through the official channel on this page.

Going out of scope, accessing third-party data beyond what is necessary, degrading the service, attempting extortion or publishing before what was agreed ends the safe harbor for that case.

This authorisation binds Borai only. It does not extend to third parties — infrastructure providers, payment gateways and other vendors have their own rules — and you remain subject to applicable law, including the law of your own jurisdiction.

9. Personal data and the LGPD

If during testing you come across someone else's personal data — name, national ID number, phone, e-mail, photo, purchase history:

1. Stop immediately. Do not continue exploiting it to measure the size of the leak.
2. Do not download, copy, store or share the content.
3. Tell us in the report, with an estimate of the volume and type of data exposed.
4. Delete any accidental copy as soon as we confirm receipt.

Following these steps protects you and protects the people who use Borai. As data controller, we have a duty to notify the Brazilian data protection authority (ANPD) and the affected individuals when an incident may create relevant risk, under article 48 of Law 13,709/2018, the LGPD. The more precise your account, the more accurate that notification is.

The data you send us in a report — name or handle, e-mail and technical content — is processed for triage, remediation and public credit, on the basis of legitimate interest, and named credit only happens with your authorisation. Details in our Privacy Policy, published in Portuguese.

10. Recognition

For every valid, unique and fixed report, you receive:

• A permanent Hall of Fame entry on this page, with the name or handle you choose and, if you want, a link to your profile. The page is indexable and the credit is never removed.
• A named mention in the security posts we publish on our channels every six months, celebrating everyone who contributed in the period.
• A verifiable certificate stating the level of your finding, detailed just below.
• A human, technical response, with no automated form and no silence.

Verifiable certificate

Every valid, unique and fixed report produces a certificate, automatically and without you having to ask. It is issued by the Borai platform itself, through the same mechanism that issues attendance certificates to people who attend an event on our platform. It is not a hand-made PDF: it goes through the same issuance, the same code and the same verifier as any other certificate we produce.

Each certificate carries a verification code printed on the document. Anyone — a recruiter, a client, a review panel — can check its authenticity in the public verifier, with no account and no login, at:

https://borai.app.br/certificados/verificar/<code>

Verification is public and does not depend on us: you never have to ask us to confirm anything, and whoever checks does not wait on a reply from us. The PDF is generated on demand from the code, is never stored, and the code stays valid indefinitely.

Each certificate shows:

• A unique verification code;
• The name or handle you chose;
• The level of the finding — critical, high, medium or low — per the scale in section 7;
• The broad category of the flaw, such as "authorisation" or "ticket validation";
• The month of the report and the date of issue;
• Confirmation that the flaw was fixed and the report followed this policy.

Consistent with the aggregation rule in section 7, the certificate carries no endpoint, parameter, payload or any detail that would allow the flaw to be reproduced. It attests to the contribution and the level, not the recipe.

We only revoke a certificate if the credit was obtained fraudulently, such as a report copied from someone else or a fabricated flaw. In that case the code shows as revoked in the verifier rather than simply disappearing — security history is not rewritten. A correction on the merits produces a reissue with the corrected level, not a deletion. Researchers who asked to stay anonymous still receive the certificate; they just do not appear in the Hall of Fame.

On money and swag, so there is no doubt

Today the programme offers only the items listed above. We intend, in future, to add physical swag such as stickers, t-shirts and hoodies for high and critical findings, once the company's cash position allows it. That is a stated intention, not a promise.

• No report sent today creates any entitlement to a future reward, item or payment.
• If the reward list changes, the change will be published on this page, with its own rules and no retroactive effect.
• Nothing on this page should be read as an offer, a promise of payment, or an obligation to deliver any goods.

11. Coordinated disclosure

• You may publish about the finding after the fix, or 120 days after our triage acceptance, whichever comes first.
• If we need more time, we will ask and explain why. We do not hold an indefinite veto.
• The publication must not contain user personal data, secrets of ours that are still live, or enough material to re-exploit the flaw before the fix is deployed.
• We love a good technical write-up. Let us know and we will amplify it and credit you.

12. Contact and validity

Official channel for security reports: security@borai.app.br. This address is also published in our security.txt, per RFC 9116.

For anything that is not security, use contato@borai.app.br.

We may update this policy at any time. The version in force is always the one published on this page, and it governs reports sent while it is live. This English version is the primary one; the Portuguese version is kept in sync and prevails in case of any legal dispute under Brazilian law.

13. Hall of Fame

People who responsibly reported real flaws in Borai, most recent first. The credit is permanent.

Each entry records the name or handle the person chose, the level of the finding, the affected area in broad terms and the certificate code, which leads to the public verifier. Following the aggregation rule in section 7, the Hall never publishes technical detail that would allow a flaw to be re-exploited, nor data about anyone who chose to remain anonymous.