Bug Bounty Program

Last updated 27 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.
Report only by email. Do not test our live chat or send reports or test messages through it: the chat runs on Intercom, which is out of scope, and nothing sent there counts as a report.
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 yourname+bugbounty@gmail.com, at an inbox you control). 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; if a legal check delays a payment, we tell you why and when (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. The one exception is the measurement hosts' DNS server, listed below.

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.
files.betterteam.com	Our file host: the resume, attachment and other file links the dashboard gives you, and their access controls.
app.betterteam.com	Our old app: redirects to the dashboard, job feeds and the old API.
careers.betterteam.com	Our own hiring site: its jobs are real, and real people apply to them. You may view its job pages and application form, but never send the form: applying there is a ban (see Disqualification).
betterteambugbounty.betterteam.com	Our test career site for this program, with test jobs you may apply to. It is the only place where you may send applications: up to 10 in total across all its jobs, counting all your accounts and anyone testing with you, and counting attempts that fail. More than 10 needs our written approval of a test plan (see the rules below).
Your own trial's career site	The career site of a trial account you created (yourcompany.betterteam.com). Its jobs stay unpublished; never apply to them (see Disqualification).
Our Google Cloud Storage buckets	storage.googleapis.com, reached through links our app gives you, such as your own logo or file links: access controls on our buckets, such as listing, reading or writing objects that are not yours, and links that should expire but don't. Stop at the first proof: one listing response or one object name is enough. Never open, download or change another customer's or applicant's file. Bugs in Google's platform itself go to Google.
s.betterteam.com	Our public static file host (a Google Cloud Storage bucket served through Cloudflare): the files it serves and the bucket's access controls, under the same limits as the bucket row above.
i.betterteam.com and *.i.betterteam.com	Our measurement hosts, on Fastly and our own servers, including their DNS server. No load testing or flooding, including DNS queries.
srp.betterteam.com and srp-api.betterteam.com	Proxies that forward to Segment, our analytics vendor. Only our proxy setup is in scope, such as forwarding to hosts it should not, or passing on cookies or headers it should drop. Segment's own service is not.

Out of scope

betterteam.net and betterteam.xyz: our staging and test environments.
Our customers' career sites: every *.betterteam.com career site other than betterteambugbounty.betterteam.com, careers.betterteam.com and your own trial's, and any customer career site on its own domain. They are out of scope for all testing, not only applications: do not send them test requests. Applying to their jobs is a ban (see Disqualification).
Publishing jobs in your own trial. Applications go only to betterteambugbounty.betterteam.com, within its limit; applying anywhere else, including to jobs in your own trial, is a ban (see Disqualification).
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).
We pay rewards in US dollars by PayPal or bank transfer; if your bank cannot receive US dollars, we may, with your agreement, pay the US-dollar amount in your local currency, at our payment provider's exchange rate on the day we send it. We cannot pay in crypto.

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.
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 in our own app where they let an attacker guess something secret. Sign-in, password reset and two-factor codes are run by WorkOS (see below).

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, including script you put in your own career page, jobs or settings that runs only for you, for example in the dashboard's designer or previews. Each company has a single dashboard user.
Software version disclosure.
Missing rate limits with no security impact.
Getting past our bot check or other anti-automation with no further security impact, for example by sending browser-like headers.
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.
Issues that need access to the victim's unlocked device or browser, such as pages shown by the Back button after logout or data in the browser's storage.
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.
Our own monitoring, such as analytics or session replay, recording what visitors do or type, where only our team can see the recordings.
Purging pages from our CDN cache, or anything else whose only effect is extra load on our servers.
CSRF on login, logout or forms that change nothing important.
Sign-in, signup, password reset, two-factor setup and one-time codes: WorkOS runs these flows, so report problems in them to WorkOS. What our own app does after sign-in stays in scope.
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.
Showing that invite, signup or password-reset emails can be sent to any address, unless you can put your own text in them. Send them only to addresses you control.
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.

Known issues

We already know about these, so reports of them do not earn a reward. Duplicates and already-known issues are covered by section 7 of the terms.

Existing sessions stay valid after a password change, after two-factor authentication is turned on and after logout (fix in progress).
The old app at app.betterteam.com serves a JavaScript source map (removal in progress).
Free trials can create jobs without a subscription and have no server-side job limit (by design).
Dashboard export links answer differently for a file that exists and one that does not, without serving the file (informational).
Dashboard session cookies are set for all of betterteam.com, not only the dashboard (fix in progress).
Resume links on files.betterteam.com work without signing in and do not expire (fix in progress).

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). Made-up company details are fine when you sign up. We do not create accounts for you, unblock hosting provider addresses at signup, or relax rate limits or other protections for testing. If your employer uses Betterteam, do not test with its account; start your own free trial instead. You may create separate trial accounts to test across accounts. Use only email addresses you control, for your trial accounts and for any applicant you make up: any email you cause us to send, such as an interview invite, a rejection or a password reset, must go to an address you control. Made-up names and other details are fine. Never touch other customers' data, and never message real applicants or customers as a test. Do not promote test jobs or send them to job boards. If a step would contact someone else or create a charge, stop, ask us and wait for our written yes.
Jobs, applications and career sites:
- Your own jobs: you may create jobs in your own trial and test them in the dashboard without asking us. They wait for our review and do not go public; that is expected.
- Where to apply: betterteambugbounty.betterteam.com is the only career site where you may send applications. Send no more than 10 there in total, across all its jobs, counting all your accounts and anyone testing with you, and counting attempts that fail, with made-up names and details and an applicant email address you control.
- Everywhere else: never send an application, resume, file or message to any other job: our own jobs on careers.betterteam.com, any customer's job on any career site, any job on a partner job board, or any job in your own trial, published or not. That includes made-up details and requests you expect to fail. Viewing careers.betterteam.com's job pages and application form is fine; customers' career sites are out of scope. One application anywhere else is a ban (see Disqualification).
Test plans: if a test needs more than 10 applications to betterteambugbounty.betterteam.com, email us first with what you plan to test and why it needs them, and wait for our written approval before you go over 10. Each application takes us time to look after, so we approve a plan only if at least one of these applies:
- Your plan is novel: it follows up something specific you have already seen in our app that only more applications can settle, and says what that is. A list of standard checks that would fit any web app is not enough.
- You have already sent us at least one report that we confirmed as valid.
- You have a profile on another bug bounty platform, such as HackerOne, Bugcrowd, Intigriti or YesWeHack, that shows rewarded reports, and you show us it is yours, for example by adding your ticket number to the profile while we check.
If approved, we tell you in writing your new limit for betterteambugbounty.betterteam.com, counting the applications you have already sent. Approval never covers applications anywhere else.
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 (a chain shown entirely within your own test accounts is fine; see Rewards), 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 script anything that sends email, other than a few messages (10 at most) to your own address to show an issue, and do not create jobs or applicants in bulk or spend money. No denial of service, no load or stress testing, no spam, no phishing, no social engineering and no physical access.
Automated and AI-assisted tools must follow these rules too. You are responsible for every request they send, and you must check each finding yourself before you report it: look at the actual requests and responses, or screenshots, and confirm they show the issue working; an AI agent's own summary is not enough. The request limit above counts every request a script sends and every page an agent opens or form it submits, but not the images, scripts and other files the browser loads for a page, or ordinary browsing by a person.
Prove issues with harmless markers. Do not upload or host working phishing pages, login forms, pages that redirect to other sites or anything that collects data, even in your own account. To show an open redirect in our app, a link that lands on example.com is enough.
Use security@betterteam.com for everything about the program. Do not contact our support team or live chat about your testing.
Keep the issue between us until the Disclosure section below allows you to publish.
To show a missing limit, a few requests or uploads are enough. Do not fill storage or quotas.
Do not degrade the service for anyone else while you test.

Disqualification

This section is part of the rules of testing. We treat each of the following as a material or deliberate breach under sections 2 and 7 of the terms, which ends your eligibility (a ban, on this page): we pay no reward for any of your reports that we have not already paid, including reports you sent earlier, and we approve no test jobs for you. It does not change the safe harbor for research that followed the rules.

Applying to a real job, even once. Every job is a real job except the test jobs on betterteambugbounty.betterteam.com: that covers our own jobs on careers.betterteam.com, any customer's job on any career site, any job on a partner job board and any job in your own trial, published or not. Applying means submitting, or trying to submit, the application form, a resume or other file, or a message to the job, under any account, email address or name, including made-up applicant details, by you or anyone working with you.
Sending more than 10 applications in total to betterteambugbounty.betterteam.com without an approved test plan, or more than your plan allows.
Heavy automated traffic: sending well over the rate limit in the rules of testing, or going over it again after a slip.
Causing our systems to send email, such as password resets, invites or applicant emails, to addresses you do not control, or scripting email in bulk, even to your own address.

A one-off slip under the automated traffic or email rules that you stop at once and tell us about is not a ban. That exception does not cover applying to a real job: one application is enough for a ban. If you think we have flagged you by mistake, email security@betterteam.com and we will look at it again.

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