Bug Bounty Program

Last updated 22 October 2026

Betterteam is a hiring tool used by about 5,000 small businesses, and our customers trust us with their applicants' data. If you find a security problem in our site or app, tell us: we will look into it, thank you, and pay a reward for eligible reports under the rules below. This page runs the program; the Bug Bounty Program Terms are the agreement and include several sections of this page. The program opened on 22 October 2026.

How to report

Email security@betterteam.com with the subject "Bug bounty: <short title>". One root cause per email: issues that share a cause or a fix go in the same email. You do not need to know our internal cause; if you are unsure, list related issues together.
Include the affected URL or endpoint, steps to reproduce, the impact as you see it, proof (the request and response, or a screenshot), and the trial account you tested with.
Show the issue working, with the least intrusive proof. A report without a working proof does not earn a reward. Never break the rules or touch other people's data to prove impact; if more proof would need that, stop and tell us what you found.
Attach screenshots and videos to your email; do not upload them anywhere public, and mask any real secrets and personal data you include. If the details are sensitive, email us first without them, and we will offer an encrypted channel within 3 business days.
Sign up for your trial with an email address that contains "bugbounty" (for example you+bugbounty@example.com). Where you can, add the header X-Bug-Bounty: <your trial account email or a handle> to requests you send to in-scope hosts. Both help us tell your traffic from an attack and speed up triage; neither is proof of authorization or changes what you may test, and the header is optional.
No reply within 5 business days? Send a short follow-up, without attachments, with "Follow-up" in the subject. For active exploitation or exposed personal data, start the subject with "Urgent".
To be eligible for a reward, include a line in your report, or email us before you start testing, that you accept the Bug Bounty Program Terms dated at the top of the terms page; a report without that line is still welcome and covered by the safe harbor, which never depends on acceptance.

What you can expect

We aim to confirm we received your report within 3 business days, and aim to give you our triage decision (valid, severity, duplicate or out of scope) within 10 business days.
We aim to tell you when the status changes, and to update you at least once a month while we work on a fix. If you disagree with a decision, you can ask once for reconsideration within 30 days (section 7 of the terms).
We pay within 30 days of the later of confirming your report and receiving your payment and tax details (section 8 of the terms). A payment is not notice of a fix; we tell you separately when the issue is fixed.
We may mitigate an issue or accept the risk instead of making the fix you suggest. If we close a report without a fix, we tell you; that does not cancel your reward or extend the disclosure window.
Once it is fixed we may ask you to check our fix; we say in advance whether that check is paid.

Scope

In scope

The hosts below, including the API endpoints and file links they serve. Only the web application on those hostnames over HTTPS is in scope: not other ports, mail services or the servers' addresses.

Host	What it is
www.betterteam.com	Our website.
dashboard.betterteam.com	The Betterteam web app (job posting, applicant tracking, billing) and its API, including the file links it serves.
app.betterteam.com	Redirects to the dashboard; job feeds.
Career sites	*.betterteam.com (for example your-company.betterteam.com) and careers.betterteam.com: job pages, application forms, resume uploads. Submit applications, files or messages only to the career site of a trial account you created; never send a fake application to a real customer's site or to careers.betterteam.com.

Out of scope

betterteam.net and betterteam.xyz: our staging and test environments.
Anything not listed above, including services that vendors run for us under our domain (for example help, support and login) and the vendors' own platforms (Cloudflare, Fastly, Stripe, Intercom, Zendesk, WorkOS, Google, Indeed, ZipRecruiter, LinkedIn, Monster). Report a vendor's bug to the vendor. Our configuration of a vendor's service is in scope only where it can be tested entirely through requests to the in-scope hosts.
How Indeed, ZipRecruiter, LinkedIn and Monster show or process the jobs we send them. What we put in the feed is ours: an unpublished job, a hidden field or applicant data in a feed is in scope.
If you notice something exposed outside the scope, report it without probing. Asking is not authorization: you may test only what this scope lists, and asking about anything else does not authorize testing it until we say yes in writing; silence or a reply confirming receipt is not permission. We may add a host to the list.
One exception: a subdomain takeover or a dangling DNS record on any of our domains (betterteam.com, betterteam.net, betterteam.xyz, betterteam.au, betterteam.com.au, bte.am) is in scope, rated by impact. Show the dangling record and, at most, a harmless proof page.

Rewards

Severity	CVSS v3.1 score	Reward (USD)
Critical	9.0 to 10.0	$1,000 to $2,000
High	7.0 to 8.9	$400 to $800
Medium	4.0 to 6.9	$150 to $400
Low	0.1 to 3.9	$50 to $150
Informational	None	No reward

The examples below are illustrative, not fixed ratings. How we set severity, the minimum for each band, duplicates, priority and grouping are in section 7 of the terms.
An exceptional report, or a chain of issues, can earn more. You may describe a chain, or show one entirely within your own test accounts; before any step that needs more access, ask us and wait for our written yes.
An issue confined to www.betterteam.com, our static marketing site, earns the minimum of its band. That does not apply where safe evidence, or our own check, shows the issue can reach customer or applicant data; never access anyone's data to show that.
Which reward table applies is set by section 13 of the terms; who can receive a reward, including the age rules, by section 2; payment and tax forms by section 8 (sanctions checks are in section 2).

Examples

Critical

Remote code execution.
SQL injection reaching customer data.
Authentication bypass into another customer's account.
Resumes or applications of other customers' applicants readable across accounts.
Taking over another customer's dashboard account without their help.

High

Access to another customer's applicants or jobs through a broken object or function authorization check.
Stored XSS in the dashboard.
Stored XSS in a career site application form that runs when an employer views applications.
Privilege escalation.
Account takeover with little or no user interaction.
Changing what applicants see on another customer's job page or application form, such as the apply link or the text.

Medium

CSRF on an action that matters.
Reflected XSS.
Sensitive data in responses or logs.
Authorization flaws with limited reach.
One career site exposing one applicant's details through a guessable link.

Low

Minor information leaks.
Open redirects.
Missing rate limits where they let an attacker guess passwords or codes.

What we do not pay for

Findings from automated scanners with no working proof.
Missing security headers.
SPF, DKIM and DMARC settings.
Cookie flags on non-sensitive cookies.
Clickjacking on pages with no state change.
Self-XSS.
Software version disclosure.
Missing rate limits with no security impact.
Best-practice advice.
Opinions on password or session policy.
Account enumeration through login, signup or timing.
Email spoofing.
Social engineering of our staff, customers or partners.
Physical attacks.
Denial of service.
Issues that need a rooted device, a compromised network or malware already on the victim's machine.
Vulnerabilities in dependencies whose public security advisory came out less than 14 days before your report.
TLS settings and cipher choices, unless you show a working attack.
Text or link injection that cannot run script or trick a user into a harmful action.
Problems that only affect browsers more than two versions behind their current stable release.
Formula injection in exported spreadsheets, unless you show harm beyond the spreadsheet's own warning.
CSRF on login, logout or forms that change nothing important.
Error pages or stack traces that show nothing sensitive.
Autocomplete on forms.
The existence of files we publish on purpose, such as robots.txt and security.txt; secrets or personal data found in them are still worth reporting.
Tabnabbing.
Using invite, signup or password-reset emails to send messages to an address you choose, unless you can put your own text in them.
Posting a fake, spam or misleading job from your own account, or showing that a job can contain any text. Script that runs in someone else's browser is in scope.
Being able to email your own test applicants from your own account.
Downloading or scraping published jobs, career sites or job feeds: they are public on purpose. Unpublished jobs or applicant data showing up in them is in scope.
A redirect a customer set on purpose, such as a job's external apply link. An open redirect that anyone can point anywhere stays in scope.
Keys or tokens a customer published themselves, for example on their own website. Tell us and we will let them know; do not use them.

You are welcome to report these anyway. We review security reports and fix by risk, but these do not earn a reward. Reporting them does not authorize prohibited testing: denial of service, social engineering and physical attacks stay off limits.

Vulnerabilities in third-party software or libraries are not paid unless you show a Betterteam-specific exploit. Issues we already know about: none listed yet. Duplicates and already-known issues are covered by section 7 of the terms.

Rules of testing

These rules are part of the Bug Bounty Program Terms; section 5 of the terms adds the legal conditions.

Test only with accounts you created: start a free trial (no card needed) and use made-up jobs and applicants. If your employer uses Betterteam, do not test with its account, even as an admin. Start your own free trial instead. You may create separate trial accounts to test across accounts; use only email addresses you control. Any email the dashboard sends to an applicant, such as an interview invite or a rejection, must go to an address you own. Never touch other customers' data, never apply to a real job or message real applicants or customers as a test, and do not apply to or message jobs on partner job boards as part of testing. Do not promote test jobs or send them to job boards, and delete your test jobs and applicants when you finish. If a step would publish a job, contact someone else or create a charge, stop, ask us and wait for our written yes.
Career sites: you may test any career site, including careers.betterteam.com, but submit applications, files or messages only to the career site of a trial account you created. Never send a fake application to a real customer's site or to careers.betterteam.com.
Stop at the first proof. Do not intentionally access, read, copy, change or delete data that is not yours, do not use one finding to look for the next inside our systems, and do not pivot from our systems into a vendor's. Do not keep access or install anything persistent. If you find a Betterteam password, key or token, report it and do not use it; credentials from breach dumps or stealer logs are not rewarded.
If you encounter other people's data, stop, do not keep it, and redact what you already captured; the full rule is section 10 of the terms.
No automated vulnerability scanners, broad crawling or fuzzing. Scripts that repeat a request you wrote by hand are fine, at under 5 requests in any one second in total across you, anyone you work with and all your accounts; stop at once if you see unexpected errors or slowdowns. Do not automate anything that sends email, creates jobs or applicants in bulk, or spends money. No denial of service, no load or stress testing, no spam, no phishing, no social engineering and no physical access.
Use security@betterteam.com for everything about the program. Do not contact our support team about your testing, and do not send test messages through the support chat.
Keep the issue between us until the Disclosure section below allows you to publish.
Do not degrade the service for anyone else while you test.

Safe harbor

If your research follows the scope and rules above, we consider it authorized: we will not bring a legal claim against you for it under anti-hacking laws such as the Computer Fraud and Abuse Act or under the anti-circumvention rule of the Digital Millennium Copyright Act, we waive the parts of our Terms and Policies that would get in its way, and we treat it as good-faith research. If someone else brings a claim over it, we will say that it was authorized. The binding text, with the conditions, is section 3 of the Bug Bounty Program Terms.

Disclosure

You may publish once the issue is fixed or on day 90 from our acknowledgement of your report (or from 3 business days after you sent it, if we have not acknowledged), whichever comes first. We may ask once, before day 90, to extend that by up to 30 days. Tell us at least 7 days before you publish. The full rule, including duplicates and rejected reports, is section 9 of the terms.

Questions

Email security@betterteam.com.

Bug Bounty Program Terms
Our machine-readable security contact: /.well-known/security.txt