Starbucks
External Program
Submit bugs directly to this organization
Starbucks
Starbucks believes in a program that fosters collaboration among security professionals to help protect our systems and customers’ personal information from malicious activity and to help set security policies across our organization. We value the security and safety of our customers’ personal information above all.
###For the protection of our customers, Starbucks does not publicly disclose, discuss, or confirm security matters before comprehensively investigating, diagnosing, and fixing any known issues.
Starbucks is introducing five Child Programs to the HackerOne platform. Each of the Child Programs has specific scope, generally based on geographical regions. If you do not see an asset listed as a best fit for a regional program, or are unsure where to submit a report, please use the Parent Program for submissions. Based on the asset in the report, your report may move from the Parent Program to a regional program.
Program’s Geographic Regions:
(Parent Program) – North America Latin America and Caribbean Europe, and Middle East and Africa China Japan Asia Pacific and India
Table of Contents
Legal
Program Eligibility
Program Rules
What is required when submitting a report?
What happens after you submit a report?
How do I make my report great?
What causes a report to be closed as Informative, Duplicate, N/A, or Spam?
Program
Starbucks reserves the right to modify terms and conditions of this program and your participation in the program constitutes acceptance of all terms. Please check this site regularly as we routinely update our program terms and eligibility, which are effective upon posting. We reserve the right to cancel this program at any time. Must be 18 or older to be eligible for an award.
You must agree and adhere to the Program Rules and Legal terms as stated in this policy.
You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty.
You must be available to supply additional information, as needed by our team, to reproduce and triage the issue.
Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability.
Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible.
Starbucks partners (employees) and vendors are not eligible for participation in this program.
Read and abide by the program policy.
Perform testing using only accounts that are your own personal/test accounts or an account that you have the explicit permission from the account holder to utilize.
Exercise caution when testing to avoid negative impact to customers and the services they depend on.
Stop when unsure. If you think you may cause, or have caused, damage with testing a vulnerability, report your initial finding(s) and request authorization to continue testing.
Do not Brute force credentials or guess credentials to gain access to systems.
Do not participate in denial of service attacks.
Do not upload shells or create a backdoor of any kind.
Do not engage in any form of social engineering of Starbucks employees, customers, or vendors.
Do not engage or target any Starbucks employee, customer or vendor during your testing.
Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own.
Do not change passwords of any account that is not yours or that you do not have explicit permission to change. If ever prompted to change a password, stop and report the finding immediately.
Do not publicly disclose any vulnerabilities proposed to Starbucks. The Starbucks program is strictly confidential.
Do not submit reports here as a means to engage us to buy your products or services. Please direct your sales inquiries through proper channels.
Any violation of these rules can lead to a program ban.
Report Submissions
Provide the information asked for by the new report form, following the instructions there. Some important considerations include:
Title – this should be a quick and clear summary of your issue.
Asset – this should match exactly the asset you are reporting, or “Other”.
Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity.
Weakness – select the most appropriate vulnerability type.
Description – provide all the requested fields.
Starbucks staff will perform the initial validation of your report. They will confirm it is well understood, reproducible, has security impact, and is otherwise in line with our program policy and scope.
Starbucks may close the report as "Duplicate", "Informative", "N/A", "Spam", or continue to work with you if more information is needed.
Once validated by Starbucks, the staff will move the report to “pending program review”, letting you know in the report with a short message to that effect.
The Starbucks team will review the report with the internal asset team to verify the vulnerabilities reported. As a global company, we often need to engage with teams across multiple time zones so we may need additional time to fully validate the report. Once an internal team has confirmed the report as valid, we will move the report to “Triaged” state.
"Triage" means the report is valid & we intend to take action on. During this time, we will work with our internal teams to resolve the issue and follow up to close the report as "Resolved".
Reward amounts are calculated based on the numerical CVSS score assigned to the report.
We strive to pay bounty on "Triage" and will do so when there is high confidence in the accuracy of the assigned scope and severity. Occasionally, we may need to delay payment until we fully investigate the details of a report.
All bounty amounts will be at the discretion of the Starbucks Bug Bounty team.
Reports submitted using methods that violate policy rules will not be eligible for reward.
To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.
Reports where the researcher has confirmed and reported the same vulnerability on multiple assets, with the same root cause, may qualify for a 1.5 multiplier on their bounty award. Do not submit duplicate reports for the same issue across multiple sites as the duplicates will be closed and the issue will be treated as one report.
While we aim for consistency, previous reports and prior bounty amounts do not set a precedent and are not to be used for negotiating a higher reward. Changes to policy and the occasional human error should be considered.
Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected.
As of October 2024 Starbucks is no longer accepting disclosure requests. All vulnerabilities are strictly confidential.
Great reports lead to quicker resolution and more accurate reward.
Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited.
Utilize the CVSS v3 calculator to thoughtfully score your report.
Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding.
Be sure to include the environment used for testing (browsers, app version devices, tools, configuration), any accounts used during testing and also provide your IP address if reporting on an asset that might be logging that information so that we can easily filter your results to help validate your report.
Include your recommendations to resolve the issue.
Be responsive to requests for additional information.
Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved.
Always be polite and respectful to HackerOne and Starbucks team members.
For more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html
These are just some examples of what may drive your report to a particular type of closure and are not intended to form a complete list.
Incomprehensible, abusive behavior or harassment within a report, or reports clearly having no effort to identify a security impact may be closed out as Spam.
Submitting reports with an apparent intent to sell a product or service to detect or prevent the vulnerabilities described in the report are likely to be closed as Spam.
When reports on the same asset using the same attack vector/exploit are received, only the first report received is triaged. All other subsequent reports will be marked as a duplicate.
A vulnerability reported on one domain may exist on another domain if the sites share the platform. For example, an issue reported for starbucks.com may also be present in the exact same way on starbucks.ca and the issue can be resolved on both sites with the same fix. We treat the issue as one bug and will close out others as duplicates. Rest assured; we do take the existence of the vulnerability present on multiple sites into consideration during reward time.
Issues with minimal impact or relating to common security practices that are not prioritized for remediation.
Reports notifying us of broken links or abandoned Social Media accounts.
Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls.
Issues which are not consistently reproducible. If reports cannot be reproduced and are not actionable, we may close as informative. It is possible to re-open those reports at a later date when new information is presented.
Notification of an existing indication of compromise. For example, if you report a subdomain takeover you encounter but did not execute yourself, this would be closed as informative.
Violating program rules defined by HackerOne or those defined within this Starbucks program policy.
Reports submitted for assets that clearly do not belong to Starbucks.
Reports identifying issues described in our list of Exclusions.
Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions.
SDTO reports without a working proof of concept confirming you have control over the subdomain in question.
Information disclosures that might have the word Starbucks in it (student projects in Github, etc.) but clearly do not belong to Starbucks or do not present security impact.
Exclusions
*Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance. *
Web cache poisoning where the extent of the impact is denial of service with minimal demonstrated risk (such as taking down a low impact web element for under a minute)
Exposed third party API keys that do not demonstrate clear and immediate security risk/impact.
Attacks that require a victim user to manually enter scripted and/or malicious commands.
Information disclosures/leaks involving online documents or forms that do not pose an immediate security risk.
Attacks that are focused on resource exhaustion and/or abusing third party subscription services involving platforms not owned by Starbucks.
CORS (Cross Origin Resource Sharing) policy misconfiguration issues that leverage proxied or forwarded traffic.
Attacks which require initial navigation to a third party attacker website in order for the attack to succeed. (Examples include: POST-based Reflected XSS, CORS misconfigurations, CSRF, Cross-origin Opener issues)
Email bombardment attacks against victim users.
SDTO (or reports of similar nature) that do not demonstrate a valid PoC of taking over the target subdomain in question.
Reports from automated tools or scans.
Reports of credentials exposed by other data breaches / known credential lists. (Please refer to the Appropriate Proof of Concepts at the bottom of the page for specific exceptions to this exclusion)
Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers.
Reports about insecure SSL/TLS configuration.
Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing).
Presence of publicly accessible login pages.
Use of outdated software/library versions.
Use of a known-vulnerable library without a description of an exploit specific to our implementation.
OPTIONS/TRACE HTTP method enabled.
Disclosure of known public files or directories.
Presence of autocomplete functionality in form fields.
Cookies that lack HTTP Only or Secure settings.
Clickjacking and issues only exploitable through clickjacking.
Attacks requiring physical access to a user's device or MITM attacks.
Attacks dependent upon social engineering of Starbucks employees or vendors.
Username enumeration based on login, forgot password, account creation and registration pages.
Password or account recovery policies, such as reset link expiration or password complexity.
Session management concerns such as session duration, concurrent active sessions or session invalidation triggers.
Lack of email address verification during account registration.
Enforcement policies for brute force or account lockout.
Rate-limiting issues.
Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these.
Configuration of or missing security headers.
Mixed content issues.
CSRF on logout.
CSRF on forms that are available to anonymous users.
Self-XSS and issues exploitable only through Self-XSS.
Content spoofing/text injection.
Hyperlink injection in emails using forms available to any user.
Lack of obfuscation in mobile apps.
Absence of certificate pinning.
Lack of jailbreak detection in mobile apps.
Helpful Hints
Read & follow the rules.
Generating fraudulent Starbucks Card reloads or coupons, or simply getting free coffee, in an effort to "steal money from Starbucks" is typically not evaluated as a critical issue.
Valid reports would be the type of report that identifies security impacts such that you’d find in the OWASP top 10: https://owasp.org/www-project-top-ten/ and mobile top 10: https://owasp.org/www-project-mobile-top-10/.
If your motivation is financial compensation, you are more likely to receive a bounty by finding and demonstrating a security impact within the published scope than by submitting a bug that's outside of scope and trying to convince us why you believe it’s a security impact to Starbucks.
SQLi - A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you.
RCE - A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system.
Subdomain Takeovers (SDTO) – You are required to demonstrate that the domain has been taken over by you and is still in your possession – this avoids false positives and claim-jumping. A valid demonstration is a Proof of Concept html file hosted by you on the site with your HackerOne username. Our preference is for you to place your hosted proof of concept in a sub-directory and include your HackerOne username as a comment in the markup rather than having the file be the primary landing page of the domain. Ensure to include the URL to this file in your report. SDTO reports submitted by you in which you cannot demonstrate your ownership of the domain are not reward eligible.
Web cache poisoning - We are currently not accepting reports where the extent of the finding is only denial of service or asset misconfigurations with no risk. For us to accept a web cache poisoning report, you are required to provide a video PoC that is valid and shows a follow on attack, such as cached XSS, fetching a resource from a non-Starbucks owned asset, or any other meaningful attack that can show more than just a minor misconfiguration on a target endpoint.
Exposed/Leaked Credentials - We typically do not accept exposed or leaked credential reports as per our Program Guideline Exclusions. The primary exception to this rule would be if the leaked credential(s) are sourcing from an InfoStealer Malware log, and you are able to provide proof+context of the infected asset by attaching the InfoStealer log as part of the report submission. Reports that have actively working credentials and the respective infostealer log are eligible for a small bounty if the involved infected host is classified as a Starbucks asset.
FAQ's
Set the asset type to the primary application you were testing. Ensure that your write up, includes the specifics for your proof of concept detailing:
How you tested this
Which back end API call(s) had the vulnerability
Starbucks will review the report and determine whether it remains in-scope and bounty eligible under that primary asset.
A mobile application example can be found within our current scope:
Android Play Store: com.starbucks.singapore
Assets eligible for bounty referenced directly by this app:
https://mobile.starbucks.com.sg
A web application example might constitute calls to a back-end API via JavaScript as part of the application process flow. If the API had the vulnerability, but was initiated by the web application, then this would be considered when determining if it is bounty eligible.
Thank you for helping keep Starbucks and our users safe!