[{"id":3762639,"new_policy":"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.  \n\n  \n###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. \n\nStarbucks 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. \n\n  \n\nProgram’s Geographic Regions: \n\n(Parent Program) – North America \nLatin America and Caribbean \nEurope, and Middle East and Africa \nChina \nJapan \nAsia Pacific and India \n\n \n\n \n\n  \n\n\u0026nbsp; \n\n______________________________________________________________________________________________________________________ \n\n  \n\nTable of Contents \n\n\n______________________________________________________________________________________________________________________ \n\n  \n\n  \n\n### Program \n\n1. Legal \n\n3. Program Eligibility \n\n4. Program Rules \n\n  \n\n### Report Submissions \n\n1. What is required when submitting a report? \n\n2. What happens after you submit a report? \n\n3. How do I make my report great? \n\n4. What causes a report to be closed as Informative, Duplicate, N/A, or Spam? \n\n  \n\n### Helpful Hints \n\n### FAQ's \n\n  \n\n\u0026nbsp; \n\n  \n\n______________________________________________________________________________________________________________________ \n\n  \n\nProgram \n\n\n________________________________________ \n\n----------------- \n \n\n\n1. Legal \n\n\nStarbucks 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. \n\n----------------- \n\n\n\n2. Program Eligibility \n\n\n+ You must agree and adhere to the Program Rules and Legal terms as stated in this policy. \n\n+ You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty. \n\n+ You must be available to supply additional information, as needed by our team, to reproduce and triage the issue. \n\n+ Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability. \n\n+ Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible. \n\n+ Starbucks partners (employees) and vendors are not eligible for participation in this program. \n\n----------------- \n\n\n\n3. Program Rules \n\n\n### Do \n\n+ Read and abide by the program policy. \n\n+ 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. \n\n+ Exercise caution when testing to avoid negative impact to customers and the services they depend on. \n\n+ 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. \n\n  \n\n### Do NOT \n\n+ Do not Brute force credentials or guess credentials to gain access to systems. \n\n+ Do not participate in denial of service attacks. \n\n+ Do not upload shells or create a backdoor of any kind. \n\n+ Do not engage in any form of social engineering of Starbucks employees, customers, or vendors. \n\n+ Do not engage or target any Starbucks employee, customer or vendor during your testing. \n\n+ Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own.  \n\n+ 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.  \n\n+ Do not publicly disclose any vulnerabilities proposed to Starbucks. The Starbucks program is strictly confidential. \n\n+ 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. \n\n+ Any violation of these rules can lead to a program ban. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nReport Submissions \n\n______________________________________________________________________________________________________________________ \n\n  \n\n ----------------- \n\n\n1. What is required when submitting a report? \n\n\nProvide the information asked for by the new report form, following the instructions there. Some important considerations include: \n\n+ Title – this should be a quick and clear summary of your issue. \n\n+ Asset – this should match exactly the asset you are reporting, or “Other”. \n\n+ Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity. \n\n+ Weakness – select the most appropriate vulnerability type.  \n\n+ Description – provide all the requested fields. \n\n  \n\n----------------- \n\n\n2. What happens after you submit a report? \n\n\nStarbucks 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. \n\n \n\nStarbucks may close the report as \"Duplicate\", \"Informative\", \"N/A\", \"Spam\", or continue to work with you if more information is needed.  \n\n \n\nOnce 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. \n\n \n\nThe 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. \n\n \"Triage\" means the report is valid \u0026  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\". \n\n \n\n  \n\n  \n\n### Rewards \n\n  \n\nReward amounts are calculated based on the numerical CVSS score assigned to the report. \n\n  \n\nWe 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. \n\n  \n\n+ All bounty amounts will be at the discretion of the Starbucks Bug Bounty team. \n\n+ Reports submitted using methods that violate policy rules will not be eligible for reward. \n\n+ To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.   \n\n+ 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. \n\n+ 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. \n\n+ Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected. \n\n  \n### Core Ineligible Findings\n+ Starbucks accepts Open Redirect findings even though they are part of the HackerOne Core Ineligible Findings \n  \n\n### Disclosure Requests  \n\n  \n\nAs of October 2024 Starbucks is no longer accepting disclosure requests. All vulnerabilities are strictly confidential. \n\n  \n\n----------------- \n\n\n3. How do I make my report great? \n\nGreat reports lead to quicker resolution and more accurate reward. \n\n+ Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited. \n\n+ Utilize the CVSS v3 calculator to thoughtfully score your report.  \n\n+ Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding.  \n\n+ 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. \n\n+ Include your recommendations to resolve the issue. \n\n+ Be responsive to requests for additional information. \n\n+ Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved. \n\n+ Always be polite and respectful to HackerOne and Starbucks team members. \n\n  \n\nFor more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html \n\n  \n\n  \n\n----------------- \n\n\n4. What causes a report to be closed as Informative, Duplicate, N/A or Spam? \n\n\nThese 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. \n\n  \n\n  \n\n### Spam \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Duplicate \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n### Informative \n\n+ Issues with minimal impact or relating to common security practices that are not prioritized for remediation.   \n\n+ Reports notifying us of broken links or abandoned Social Media accounts. \n\n+ Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls. \n\n+ 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. \n\n+ 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. \n\n  \n\n### N/A \n\n+ Violating program rules defined by HackerOne or those defined within this Starbucks program policy. \n\n+ Reports submitted for assets that clearly do not belong to Starbucks. \n\n+ Reports identifying issues described in our list of Exclusions. \n\n+ Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions. \n\n+ SDTO reports without a working proof of concept confirming you have control over the subdomain in question. \n\n+ 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. \n\n  \n\n_*Exclusions*_ \n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance. * \n\n+ 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)\n\n+ Exposed third party API keys that do not demonstrate clear and immediate security risk/impact.\n\n+ Attacks that require a victim user to manually enter scripted and/or malicious commands.\n\n+ Information disclosures/leaks involving online documents or forms that do not pose an immediate security risk.\n\n+ Attacks that are focused on resource exhaustion and/or abusing third party subscription services involving platforms not owned by Starbucks. \n\n+ CORS (Cross Origin Resource Sharing) policy misconfiguration issues that leverage proxied or forwarded traffic.\n\n+ 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)\n\n+ Email bombardment attacks against victim users.\n\n+ SDTO (or reports of similar nature) that do not demonstrate a valid PoC of taking over the target subdomain in question.\n\n+ Reports from automated tools or scans. \n\n+ 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)\n\n+ Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers.  \n\n+ Reports about insecure SSL/TLS configuration. \n\n+ Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing). \n\n+ Presence of publicly accessible login pages. \n\n+ Use of outdated software/library versions. \n\n+ Use of a known-vulnerable library without a description of an exploit specific to our implementation. \n\n+ OPTIONS/TRACE HTTP method enabled. \n\n+ Disclosure of known public files or directories. \n\n+ Presence of autocomplete functionality in form fields. \n\n+ Cookies that lack HTTP Only or Secure settings. \n\n+ Clickjacking and issues only exploitable through clickjacking. \n\n+ Attacks requiring physical access to a user's device or MITM attacks. \n\n+ Attacks dependent upon social engineering of Starbucks employees or vendors. \n\n+ Username enumeration based on login, forgot password, account creation and registration pages. \n\n+ Password or account recovery policies, such as reset link expiration or password complexity. \n\n+ Session management concerns such as session duration, concurrent active sessions or session invalidation triggers. \n\n+ Lack of email address verification during account registration. \n\n+ Enforcement policies for brute force or account lockout. \n\n+ Rate-limiting issues. \n\n+ Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these. \n\n+ Configuration of or missing security headers. \n\n+ Mixed content issues. \n\n+ CSRF on logout. \n\n+ CSRF on forms that are available to anonymous users. \n\n+ Self-XSS and issues exploitable only through Self-XSS. \n\n+ Content spoofing/text injection. \n\n+ Hyperlink injection in emails using forms available to any user.  \n\n+ Lack of obfuscation in mobile apps. \n\n+ Absence of certificate pinning. \n\n+ Lack of jailbreak detection in mobile apps. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nHelpful Hints \n\n______________________________________________________________________________________________________________________ \n\n  \n\n+ Read \u0026 follow the rules. \n\n+ 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.  \n\n+ 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/. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Appropriate Proof of Concepts \n\n+ SQLi\u0026nbsp;\u0026nbsp;- A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you. \n\n+ RCE\u0026nbsp;\u0026nbsp;- A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system. \n\n+ 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.  \n\n+ 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.\n\n+ 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. \n______________________________________________________________________________________________________________________ \n\nFAQ's \n______________________________________________________________________________________________________________________ \n\n1.\tCan I get Starbucks swag? \n\n+ Starbucks does not currently offer swag. \n\n2.\tCan Starbucks provide me with a pre-configured test account or Starbucks card(s)? \n\n+ Starbucks does not offer test accounts or test cards. \n\n3.\tAre all APIs / endpoints initiated by an in-scope mobile or web application eligible for bounty? \n\n+ No. Some APIs accessed by Starbucks applications are not developed or maintained by Starbucks application development teams. If reported through our program and we can act to mitigate a vulnerability, we may triage the report as a valid finding, but it would not be eligible for bounty. \n\n  \n\n### How to proceed in this situation: \n\nSet the asset type to the primary application you were testing. Ensure that your write up, includes the specifics for your proof of concept detailing: \n\n  \n\n+ How you tested this \n\n+ Which back end API call(s) had the vulnerability \n\n  \n\nStarbucks will review the report and determine whether it remains in-scope and bounty eligible under that primary asset. \n\n  \n\nA mobile application example can be found within our current scope: \n\nAndroid Play Store: com.starbucks.singapore \n\nAssets eligible for bounty referenced directly by this app: \n\nhttps://mobile.starbucks.com.sg \n\n\nA 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. \n\n\n\nThank you for helping keep Starbucks and our users safe! \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Google API Keys\",\"details\":\"Starbucks does not accept submissions for leaked Google API Keys\"}","{\"category\":\"ServiceNow Readable Knowledge Based Articles\",\"details\":\"Starbucks does not accept submissions for ServiceNow KBA's being readable to unauthenticated users.\"}"],"timestamp":"2025-09-11T17:18:41.921Z"},{"id":3762613,"new_policy":"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.  \n\n  \n###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. \n\nStarbucks 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. \n\n  \n\nProgram’s Geographic Regions: \n\n(Parent Program) – North America \nLatin America and Caribbean \nEurope, and Middle East and Africa \nChina \nJapan \nAsia Pacific and India \n\n \n\n \n\n  \n\n\u0026nbsp; \n\n______________________________________________________________________________________________________________________ \n\n  \n\nTable of Contents \n\n\n______________________________________________________________________________________________________________________ \n\n  \n\n  \n\n### Program \n\n1. Legal \n\n3. Program Eligibility \n\n4. Program Rules \n\n  \n\n### Report Submissions \n\n1. What is required when submitting a report? \n\n2. What happens after you submit a report? \n\n3. How do I make my report great? \n\n4. What causes a report to be closed as Informative, Duplicate, N/A, or Spam? \n\n  \n\n### Helpful Hints \n\n### FAQ's \n\n  \n\n\u0026nbsp; \n\n  \n\n______________________________________________________________________________________________________________________ \n\n  \n\nProgram \n\n\n________________________________________ \n\n----------------- \n \n\n\n1. Legal \n\n\nStarbucks 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. \n\n----------------- \n\n\n\n2. Program Eligibility \n\n\n+ You must agree and adhere to the Program Rules and Legal terms as stated in this policy. \n\n+ You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty. \n\n+ You must be available to supply additional information, as needed by our team, to reproduce and triage the issue. \n\n+ Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability. \n\n+ Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible. \n\n+ Starbucks partners (employees) and vendors are not eligible for participation in this program. \n\n----------------- \n\n\n\n3. Program Rules \n\n\n### Do \n\n+ Read and abide by the program policy. \n\n+ 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. \n\n+ Exercise caution when testing to avoid negative impact to customers and the services they depend on. \n\n+ 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. \n\n  \n\n### Do NOT \n\n+ Do not Brute force credentials or guess credentials to gain access to systems. \n\n+ Do not participate in denial of service attacks. \n\n+ Do not upload shells or create a backdoor of any kind. \n\n+ Do not engage in any form of social engineering of Starbucks employees, customers, or vendors. \n\n+ Do not engage or target any Starbucks employee, customer or vendor during your testing. \n\n+ Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own.  \n\n+ 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.  \n\n+ Do not publicly disclose any vulnerabilities proposed to Starbucks. The Starbucks program is strictly confidential. \n\n+ 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. \n\n+ Any violation of these rules can lead to a program ban. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nReport Submissions \n\n______________________________________________________________________________________________________________________ \n\n  \n\n ----------------- \n\n\n1. What is required when submitting a report? \n\n\nProvide the information asked for by the new report form, following the instructions there. Some important considerations include: \n\n+ Title – this should be a quick and clear summary of your issue. \n\n+ Asset – this should match exactly the asset you are reporting, or “Other”. \n\n+ Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity. \n\n+ Weakness – select the most appropriate vulnerability type.  \n\n+ Description – provide all the requested fields. \n\n  \n\n----------------- \n\n\n2. What happens after you submit a report? \n\n\nStarbucks 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. \n\n \n\nStarbucks may close the report as \"Duplicate\", \"Informative\", \"N/A\", \"Spam\", or continue to work with you if more information is needed.  \n\n \n\nOnce 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. \n\n \n\nThe 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. \n\n \"Triage\" means the report is valid \u0026  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\". \n\n \n\n  \n\n  \n\n### Rewards \n\n  \n\nReward amounts are calculated based on the numerical CVSS score assigned to the report. \n\n  \n\nWe 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. \n\n  \n\n+ All bounty amounts will be at the discretion of the Starbucks Bug Bounty team. \n\n+ Reports submitted using methods that violate policy rules will not be eligible for reward. \n\n+ To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.   \n\n+ 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. \n\n+ 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. \n\n+ Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected. \n\n  \n### Core Ineligible Findings\n+ Starbucks accepts Open Redirect findings even though they are part of the HackerOne Core Ineligible Findings \n  \n\n### Disclosure Requests  \n\n  \n\nAs of October 2024 Starbucks is no longer accepting disclosure requests. All vulnerabilities are strictly confidential. \n\n  \n\n----------------- \n\n\n3. How do I make my report great? \n\nGreat reports lead to quicker resolution and more accurate reward. \n\n+ Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited. \n\n+ Utilize the CVSS v3 calculator to thoughtfully score your report.  \n\n+ Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding.  \n\n+ 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. \n\n+ Include your recommendations to resolve the issue. \n\n+ Be responsive to requests for additional information. \n\n+ Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved. \n\n+ Always be polite and respectful to HackerOne and Starbucks team members. \n\n  \n\nFor more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html \n\n  \n\n  \n\n----------------- \n\n\n4. What causes a report to be closed as Informative, Duplicate, N/A or Spam? \n\n\nThese 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. \n\n  \n\n  \n\n### Spam \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Duplicate \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n### Informative \n\n+ Issues with minimal impact or relating to common security practices that are not prioritized for remediation.   \n\n+ Reports notifying us of broken links or abandoned Social Media accounts. \n\n+ Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls. \n\n+ 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. \n\n+ 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. \n\n  \n\n### N/A \n\n+ Violating program rules defined by HackerOne or those defined within this Starbucks program policy. \n\n+ Reports submitted for assets that clearly do not belong to Starbucks. \n\n+ Reports identifying issues described in our list of Exclusions. \n\n+ Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions. \n\n+ SDTO reports without a working proof of concept confirming you have control over the subdomain in question. \n\n+ 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. \n\n  \n\n_*Exclusions*_ \n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance. * \n\n+ Web cache poisoning where the extent of the impact is denial of service or a misconfiguration with minimal demonstrated risk.\n\n+ Exposed third party API keys that do not demonstrate clear and immediate security risk/impact.\n\n+ Attacks that require a victim user to manually enter scripted and/or malicious commands.\n\n+ Information disclosures/leaks involving online documents or forms that do not pose an immediate security risk.\n\n+ Attacks that are focused on resource exhaustion and/or abusing third party subscription services involving platforms not owned by Starbucks. \n\n+ CORS (Cross Origin Resource Sharing) policy misconfiguration issues that leverage proxied or forwarded traffic.\n\n+ 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)\n\n+ Email bombardment attacks against victim users.\n\n+ SDTO (or reports of similar nature) that do not demonstrate a valid PoC of taking over the target subdomain in question.\n\n+ Reports from automated tools or scans. \n\n+ 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)\n\n+ Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers.  \n\n+ Reports about insecure SSL/TLS configuration. \n\n+ Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing). \n\n+ Presence of publicly accessible login pages. \n\n+ Use of outdated software/library versions. \n\n+ Use of a known-vulnerable library without a description of an exploit specific to our implementation. \n\n+ OPTIONS/TRACE HTTP method enabled. \n\n+ Disclosure of known public files or directories. \n\n+ Presence of autocomplete functionality in form fields. \n\n+ Cookies that lack HTTP Only or Secure settings. \n\n+ Clickjacking and issues only exploitable through clickjacking. \n\n+ Attacks requiring physical access to a user's device or MITM attacks. \n\n+ Attacks dependent upon social engineering of Starbucks employees or vendors. \n\n+ Username enumeration based on login, forgot password, account creation and registration pages. \n\n+ Password or account recovery policies, such as reset link expiration or password complexity. \n\n+ Session management concerns such as session duration, concurrent active sessions or session invalidation triggers. \n\n+ Lack of email address verification during account registration. \n\n+ Enforcement policies for brute force or account lockout. \n\n+ Rate-limiting issues. \n\n+ Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these. \n\n+ Configuration of or missing security headers. \n\n+ Mixed content issues. \n\n+ CSRF on logout. \n\n+ CSRF on forms that are available to anonymous users. \n\n+ Self-XSS and issues exploitable only through Self-XSS. \n\n+ Content spoofing/text injection. \n\n+ Hyperlink injection in emails using forms available to any user.  \n\n+ Lack of obfuscation in mobile apps. \n\n+ Absence of certificate pinning. \n\n+ Lack of jailbreak detection in mobile apps. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nHelpful Hints \n\n______________________________________________________________________________________________________________________ \n\n  \n\n+ Read \u0026 follow the rules. \n\n+ 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.  \n\n+ 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/. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Appropriate Proof of Concepts \n\n+ SQLi\u0026nbsp;\u0026nbsp;- A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you. \n\n+ RCE\u0026nbsp;\u0026nbsp;- A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system. \n\n+ 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.  \n\n+ 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 misconfiguration on a target endpoint.\n\n+ 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. \n______________________________________________________________________________________________________________________ \n\nFAQ's \n______________________________________________________________________________________________________________________ \n\n1.\tCan I get Starbucks swag? \n\n+ Starbucks does not currently offer swag. \n\n2.\tCan Starbucks provide me with a pre-configured test account or Starbucks card(s)? \n\n+ Starbucks does not offer test accounts or test cards. \n\n3.\tAre all APIs / endpoints initiated by an in-scope mobile or web application eligible for bounty? \n\n+ No. Some APIs accessed by Starbucks applications are not developed or maintained by Starbucks application development teams. If reported through our program and we can act to mitigate a vulnerability, we may triage the report as a valid finding, but it would not be eligible for bounty. \n\n  \n\n### How to proceed in this situation: \n\nSet the asset type to the primary application you were testing. Ensure that your write up, includes the specifics for your proof of concept detailing: \n\n  \n\n+ How you tested this \n\n+ Which back end API call(s) had the vulnerability \n\n  \n\nStarbucks will review the report and determine whether it remains in-scope and bounty eligible under that primary asset. \n\n  \n\nA mobile application example can be found within our current scope: \n\nAndroid Play Store: com.starbucks.singapore \n\nAssets eligible for bounty referenced directly by this app: \n\nhttps://mobile.starbucks.com.sg \n\n\nA 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. \n\n\n\nThank you for helping keep Starbucks and our users safe! \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Google API Keys\",\"details\":\"Starbucks does not accept submissions for leaked Google API Keys\"}","{\"category\":\"ServiceNow Readable Knowledge Based Articles\",\"details\":\"Starbucks does not accept submissions for ServiceNow KBA's being readable to unauthenticated users.\"}"],"timestamp":"2025-09-10T17:18:41.491Z"},{"id":3762612,"new_policy":"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.  \n\n  \n###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. \n\nStarbucks 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. \n\n  \n\nProgram’s Geographic Regions: \n\n(Parent Program) – North America \nLatin America and Caribbean \nEurope, and Middle East and Africa \nChina \nJapan \nAsia Pacific and India \n\n \n\n \n\n  \n\n\u0026nbsp; \n\n______________________________________________________________________________________________________________________ \n\n  \n\nTable of Contents \n\n\n______________________________________________________________________________________________________________________ \n\n  \n\n  \n\n### Program \n\n1. Legal \n\n3. Program Eligibility \n\n4. Program Rules \n\n  \n\n### Report Submissions \n\n1. What is required when submitting a report? \n\n2. What happens after you submit a report? \n\n3. How do I make my report great? \n\n4. What causes a report to be closed as Informative, Duplicate, N/A, or Spam? \n\n  \n\n### Helpful Hints \n\n### FAQ's \n\n  \n\n\u0026nbsp; \n\n  \n\n______________________________________________________________________________________________________________________ \n\n  \n\nProgram \n\n\n________________________________________ \n\n----------------- \n \n\n\n1. Legal \n\n\nStarbucks 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. \n\n----------------- \n\n\n\n2. Program Eligibility \n\n\n+ You must agree and adhere to the Program Rules and Legal terms as stated in this policy. \n\n+ You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty. \n\n+ You must be available to supply additional information, as needed by our team, to reproduce and triage the issue. \n\n+ Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability. \n\n+ Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible. \n\n+ Starbucks partners (employees) and vendors are not eligible for participation in this program. \n\n----------------- \n\n\n\n3. Program Rules \n\n\n### Do \n\n+ Read and abide by the program policy. \n\n+ 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. \n\n+ Exercise caution when testing to avoid negative impact to customers and the services they depend on. \n\n+ 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. \n\n  \n\n### Do NOT \n\n+ Do not Brute force credentials or guess credentials to gain access to systems. \n\n+ Do not participate in denial of service attacks. \n\n+ Do not upload shells or create a backdoor of any kind. \n\n+ Do not engage in any form of social engineering of Starbucks employees, customers, or vendors. \n\n+ Do not engage or target any Starbucks employee, customer or vendor during your testing. \n\n+ Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own.  \n\n+ 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.  \n\n+ Do not publicly disclose any vulnerabilities proposed to Starbucks. The Starbucks program is strictly confidential. \n\n+ 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. \n\n+ Any violation of these rules can lead to a program ban. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nReport Submissions \n\n______________________________________________________________________________________________________________________ \n\n  \n\n ----------------- \n\n\n1. What is required when submitting a report? \n\n\nProvide the information asked for by the new report form, following the instructions there. Some important considerations include: \n\n+ Title – this should be a quick and clear summary of your issue. \n\n+ Asset – this should match exactly the asset you are reporting, or “Other”. \n\n+ Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity. \n\n+ Weakness – select the most appropriate vulnerability type.  \n\n+ Description – provide all the requested fields. \n\n  \n\n----------------- \n\n\n2. What happens after you submit a report? \n\n\nStarbucks 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. \n\n \n\nStarbucks may close the report as \"Duplicate\", \"Informative\", \"N/A\", \"Spam\", or continue to work with you if more information is needed.  \n\n \n\nOnce 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. \n\n \n\nThe 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. \n\n \"Triage\" means the report is valid \u0026  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\". \n\n \n\n  \n\n  \n\n### Rewards \n\n  \n\nReward amounts are calculated based on the numerical CVSS score assigned to the report. \n\n  \n\nWe 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. \n\n  \n\n+ All bounty amounts will be at the discretion of the Starbucks Bug Bounty team. \n\n+ Reports submitted using methods that violate policy rules will not be eligible for reward. \n\n+ To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.   \n\n+ 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. \n\n+ 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. \n\n+ Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected. \n\n  \nCore Ineligible Findings\n+ Starbucks accepts Open Redirect findings even though they are part of the HackerOne Core Ineligible Findings \n  \n\n### Disclosure Requests  \n\n  \n\nAs of October 2024 Starbucks is no longer accepting disclosure requests. All vulnerabilities are strictly confidential. \n\n  \n\n----------------- \n\n\n3. How do I make my report great? \n\nGreat reports lead to quicker resolution and more accurate reward. \n\n+ Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited. \n\n+ Utilize the CVSS v3 calculator to thoughtfully score your report.  \n\n+ Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding.  \n\n+ 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. \n\n+ Include your recommendations to resolve the issue. \n\n+ Be responsive to requests for additional information. \n\n+ Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved. \n\n+ Always be polite and respectful to HackerOne and Starbucks team members. \n\n  \n\nFor more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html \n\n  \n\n  \n\n----------------- \n\n\n4. What causes a report to be closed as Informative, Duplicate, N/A or Spam? \n\n\nThese 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. \n\n  \n\n  \n\n### Spam \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Duplicate \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n### Informative \n\n+ Issues with minimal impact or relating to common security practices that are not prioritized for remediation.   \n\n+ Reports notifying us of broken links or abandoned Social Media accounts. \n\n+ Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls. \n\n+ 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. \n\n+ 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. \n\n  \n\n### N/A \n\n+ Violating program rules defined by HackerOne or those defined within this Starbucks program policy. \n\n+ Reports submitted for assets that clearly do not belong to Starbucks. \n\n+ Reports identifying issues described in our list of Exclusions. \n\n+ Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions. \n\n+ SDTO reports without a working proof of concept confirming you have control over the subdomain in question. \n\n+ 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. \n\n  \n\n_*Exclusions*_ \n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance. * \n\n+ Web cache poisoning where the extent of the impact is denial of service or a misconfiguration with minimal demonstrated risk.\n\n+ Exposed third party API keys that do not demonstrate clear and immediate security risk/impact.\n\n+ Attacks that require a victim user to manually enter scripted and/or malicious commands.\n\n+ Information disclosures/leaks involving online documents or forms that do not pose an immediate security risk.\n\n+ Attacks that are focused on resource exhaustion and/or abusing third party subscription services involving platforms not owned by Starbucks. \n\n+ CORS (Cross Origin Resource Sharing) policy misconfiguration issues that leverage proxied or forwarded traffic.\n\n+ 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)\n\n+ Email bombardment attacks against victim users.\n\n+ SDTO (or reports of similar nature) that do not demonstrate a valid PoC of taking over the target subdomain in question.\n\n+ Reports from automated tools or scans. \n\n+ 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)\n\n+ Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers.  \n\n+ Reports about insecure SSL/TLS configuration. \n\n+ Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing). \n\n+ Presence of publicly accessible login pages. \n\n+ Use of outdated software/library versions. \n\n+ Use of a known-vulnerable library without a description of an exploit specific to our implementation. \n\n+ OPTIONS/TRACE HTTP method enabled. \n\n+ Disclosure of known public files or directories. \n\n+ Presence of autocomplete functionality in form fields. \n\n+ Cookies that lack HTTP Only or Secure settings. \n\n+ Clickjacking and issues only exploitable through clickjacking. \n\n+ Attacks requiring physical access to a user's device or MITM attacks. \n\n+ Attacks dependent upon social engineering of Starbucks employees or vendors. \n\n+ Username enumeration based on login, forgot password, account creation and registration pages. \n\n+ Password or account recovery policies, such as reset link expiration or password complexity. \n\n+ Session management concerns such as session duration, concurrent active sessions or session invalidation triggers. \n\n+ Lack of email address verification during account registration. \n\n+ Enforcement policies for brute force or account lockout. \n\n+ Rate-limiting issues. \n\n+ Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these. \n\n+ Configuration of or missing security headers. \n\n+ Mixed content issues. \n\n+ CSRF on logout. \n\n+ CSRF on forms that are available to anonymous users. \n\n+ Self-XSS and issues exploitable only through Self-XSS. \n\n+ Content spoofing/text injection. \n\n+ Hyperlink injection in emails using forms available to any user.  \n\n+ Lack of obfuscation in mobile apps. \n\n+ Absence of certificate pinning. \n\n+ Lack of jailbreak detection in mobile apps. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nHelpful Hints \n\n______________________________________________________________________________________________________________________ \n\n  \n\n+ Read \u0026 follow the rules. \n\n+ 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.  \n\n+ 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/. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Appropriate Proof of Concepts \n\n+ SQLi\u0026nbsp;\u0026nbsp;- A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you. \n\n+ RCE\u0026nbsp;\u0026nbsp;- A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system. \n\n+ 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.  \n\n+ 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 misconfiguration on a target endpoint.\n\n+ 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. \n______________________________________________________________________________________________________________________ \n\nFAQ's \n______________________________________________________________________________________________________________________ \n\n1.\tCan I get Starbucks swag? \n\n+ Starbucks does not currently offer swag. \n\n2.\tCan Starbucks provide me with a pre-configured test account or Starbucks card(s)? \n\n+ Starbucks does not offer test accounts or test cards. \n\n3.\tAre all APIs / endpoints initiated by an in-scope mobile or web application eligible for bounty? \n\n+ No. Some APIs accessed by Starbucks applications are not developed or maintained by Starbucks application development teams. If reported through our program and we can act to mitigate a vulnerability, we may triage the report as a valid finding, but it would not be eligible for bounty. \n\n  \n\n### How to proceed in this situation: \n\nSet the asset type to the primary application you were testing. Ensure that your write up, includes the specifics for your proof of concept detailing: \n\n  \n\n+ How you tested this \n\n+ Which back end API call(s) had the vulnerability \n\n  \n\nStarbucks will review the report and determine whether it remains in-scope and bounty eligible under that primary asset. \n\n  \n\nA mobile application example can be found within our current scope: \n\nAndroid Play Store: com.starbucks.singapore \n\nAssets eligible for bounty referenced directly by this app: \n\nhttps://mobile.starbucks.com.sg \n\n\nA 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. \n\n\n\nThank you for helping keep Starbucks and our users safe! \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Google API Keys\",\"details\":\"Starbucks does not accept submissions for leaked Google API Keys\"}","{\"category\":\"ServiceNow Readable Knowledge Based Articles\",\"details\":\"Starbucks does not accept submissions for ServiceNow KBA's being readable to unauthenticated users.\"}"],"timestamp":"2025-09-10T17:11:37.299Z"},{"id":3761069,"new_policy":"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.  \n\n  \n###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. \n\nStarbucks 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. \n\n  \n\nProgram’s Geographic Regions: \n\n(Parent Program) – North America \nLatin America and Caribbean \nEurope, and Middle East and Africa \nChina \nJapan \nAsia Pacific and India \n\n \n\n \n\n  \n\n\u0026nbsp; \n\n______________________________________________________________________________________________________________________ \n\n  \n\nTable of Contents \n\n\n______________________________________________________________________________________________________________________ \n\n  \n\n  \n\n### Program \n\n1. Legal \n\n3. Program Eligibility \n\n4. Program Rules \n\n  \n\n### Report Submissions \n\n1. What is required when submitting a report? \n\n2. What happens after you submit a report? \n\n3. How do I make my report great? \n\n4. What causes a report to be closed as Informative, Duplicate, N/A, or Spam? \n\n  \n\n### Helpful Hints \n\n### FAQ's \n\n  \n\n\u0026nbsp; \n\n  \n\n______________________________________________________________________________________________________________________ \n\n  \n\nProgram \n\n\n________________________________________ \n\n----------------- \n \n\n\n1. Legal \n\n\nStarbucks 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. \n\n----------------- \n\n\n\n2. Program Eligibility \n\n\n+ You must agree and adhere to the Program Rules and Legal terms as stated in this policy. \n\n+ You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty. \n\n+ You must be available to supply additional information, as needed by our team, to reproduce and triage the issue. \n\n+ Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability. \n\n+ Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible. \n\n+ Starbucks partners (employees) and vendors are not eligible for participation in this program. \n\n----------------- \n\n\n\n3. Program Rules \n\n\n### Do \n\n+ Read and abide by the program policy. \n\n+ 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. \n\n+ Exercise caution when testing to avoid negative impact to customers and the services they depend on. \n\n+ 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. \n\n  \n\n### Do NOT \n\n+ Do not Brute force credentials or guess credentials to gain access to systems. \n\n+ Do not participate in denial of service attacks. \n\n+ Do not upload shells or create a backdoor of any kind. \n\n+ Do not engage in any form of social engineering of Starbucks employees, customers, or vendors. \n\n+ Do not engage or target any Starbucks employee, customer or vendor during your testing. \n\n+ Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own.  \n\n+ 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.  \n\n+ Do not publicly disclose any vulnerabilities proposed to Starbucks. The Starbucks program is strictly confidential. \n\n+ 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. \n\n+ Any violation of these rules can lead to a program ban. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nReport Submissions \n\n______________________________________________________________________________________________________________________ \n\n  \n\n ----------------- \n\n\n1. What is required when submitting a report? \n\n\nProvide the information asked for by the new report form, following the instructions there. Some important considerations include: \n\n+ Title – this should be a quick and clear summary of your issue. \n\n+ Asset – this should match exactly the asset you are reporting, or “Other”. \n\n+ Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity. \n\n+ Weakness – select the most appropriate vulnerability type.  \n\n+ Description – provide all the requested fields. \n\n  \n\n----------------- \n\n\n2. What happens after you submit a report? \n\n\nStarbucks 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. \n\n \n\nStarbucks may close the report as \"Duplicate\", \"Informative\", \"N/A\", \"Spam\", or continue to work with you if more information is needed.  \n\n \n\nOnce 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. \n\n \n\nThe 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. \n\n \"Triage\" means the report is valid \u0026  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\". \n\n \n\n  \n\n  \n\n### Rewards \n\n  \n\nReward amounts are calculated based on the numerical CVSS score assigned to the report. \n\n  \n\nWe 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. \n\n  \n\n+ All bounty amounts will be at the discretion of the Starbucks Bug Bounty team. \n\n+ Reports submitted using methods that violate policy rules will not be eligible for reward. \n\n+ To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.   \n\n+ 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. \n\n+ 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. \n\n+ Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected. \n\n  \n\n  \n\n### Disclosure Requests  \n\n  \n\nAs of October 2024 Starbucks is no longer accepting disclosure requests. All vulnerabilities are strictly confidential. \n\n  \n\n----------------- \n\n\n3. How do I make my report great? \n\nGreat reports lead to quicker resolution and more accurate reward. \n\n+ Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited. \n\n+ Utilize the CVSS v3 calculator to thoughtfully score your report.  \n\n+ Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding.  \n\n+ 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. \n\n+ Include your recommendations to resolve the issue. \n\n+ Be responsive to requests for additional information. \n\n+ Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved. \n\n+ Always be polite and respectful to HackerOne and Starbucks team members. \n\n  \n\nFor more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html \n\n  \n\n  \n\n----------------- \n\n\n4. What causes a report to be closed as Informative, Duplicate, N/A or Spam? \n\n\nThese 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. \n\n  \n\n  \n\n### Spam \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Duplicate \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n### Informative \n\n+ Issues with minimal impact or relating to common security practices that are not prioritized for remediation.   \n\n+ Reports notifying us of broken links or abandoned Social Media accounts. \n\n+ Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls. \n\n+ 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. \n\n+ 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. \n\n  \n\n### N/A \n\n+ Violating program rules defined by HackerOne or those defined within this Starbucks program policy. \n\n+ Reports submitted for assets that clearly do not belong to Starbucks. \n\n+ Reports identifying issues described in our list of Exclusions. \n\n+ Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions. \n\n+ SDTO reports without a working proof of concept confirming you have control over the subdomain in question. \n\n+ 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. \n\n  \n\n_*Exclusions*_ \n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance. * \n\n+ Web cache poisoning where the extent of the impact is denial of service or a misconfiguration with minimal demonstrated risk.\n\n+ Exposed third party API keys that do not demonstrate clear and immediate security risk/impact.\n\n+ Attacks that require a victim user to manually enter scripted and/or malicious commands.\n\n+ Information disclosures/leaks involving online documents or forms that do not pose an immediate security risk.\n\n+ Attacks that are focused on resource exhaustion and/or abusing third party subscription services involving platforms not owned by Starbucks. \n\n+ CORS (Cross Origin Resource Sharing) policy misconfiguration issues that leverage proxied or forwarded traffic.\n\n+ 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)\n\n+ Email bombardment attacks against victim users.\n\n+ SDTO (or reports of similar nature) that do not demonstrate a valid PoC of taking over the target subdomain in question.\n\n+ Reports from automated tools or scans. \n\n+ 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)\n\n+ Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers.  \n\n+ Reports about insecure SSL/TLS configuration. \n\n+ Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing). \n\n+ Presence of publicly accessible login pages. \n\n+ Use of outdated software/library versions. \n\n+ Use of a known-vulnerable library without a description of an exploit specific to our implementation. \n\n+ OPTIONS/TRACE HTTP method enabled. \n\n+ Disclosure of known public files or directories. \n\n+ Presence of autocomplete functionality in form fields. \n\n+ Cookies that lack HTTP Only or Secure settings. \n\n+ Clickjacking and issues only exploitable through clickjacking. \n\n+ Attacks requiring physical access to a user's device or MITM attacks. \n\n+ Attacks dependent upon social engineering of Starbucks employees or vendors. \n\n+ Username enumeration based on login, forgot password, account creation and registration pages. \n\n+ Password or account recovery policies, such as reset link expiration or password complexity. \n\n+ Session management concerns such as session duration, concurrent active sessions or session invalidation triggers. \n\n+ Lack of email address verification during account registration. \n\n+ Enforcement policies for brute force or account lockout. \n\n+ Rate-limiting issues. \n\n+ Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these. \n\n+ Configuration of or missing security headers. \n\n+ Mixed content issues. \n\n+ CSRF on logout. \n\n+ CSRF on forms that are available to anonymous users. \n\n+ Self-XSS and issues exploitable only through Self-XSS. \n\n+ Content spoofing/text injection. \n\n+ Hyperlink injection in emails using forms available to any user.  \n\n+ Lack of obfuscation in mobile apps. \n\n+ Absence of certificate pinning. \n\n+ Lack of jailbreak detection in mobile apps. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nHelpful Hints \n\n______________________________________________________________________________________________________________________ \n\n  \n\n+ Read \u0026 follow the rules. \n\n+ 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.  \n\n+ 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/. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Appropriate Proof of Concepts \n\n+ SQLi\u0026nbsp;\u0026nbsp;- A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you. \n\n+ RCE\u0026nbsp;\u0026nbsp;- A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system. \n\n+ 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.  \n\n+ 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 misconfiguration on a target endpoint.\n\n+ 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. \n______________________________________________________________________________________________________________________ \n\nFAQ's \n______________________________________________________________________________________________________________________ \n\n1.\tCan I get Starbucks swag? \n\n+ Starbucks does not currently offer swag. \n\n2.\tCan Starbucks provide me with a pre-configured test account or Starbucks card(s)? \n\n+ Starbucks does not offer test accounts or test cards. \n\n3.\tAre all APIs / endpoints initiated by an in-scope mobile or web application eligible for bounty? \n\n+ No. Some APIs accessed by Starbucks applications are not developed or maintained by Starbucks application development teams. If reported through our program and we can act to mitigate a vulnerability, we may triage the report as a valid finding, but it would not be eligible for bounty. \n\n  \n\n### How to proceed in this situation: \n\nSet the asset type to the primary application you were testing. Ensure that your write up, includes the specifics for your proof of concept detailing: \n\n  \n\n+ How you tested this \n\n+ Which back end API call(s) had the vulnerability \n\n  \n\nStarbucks will review the report and determine whether it remains in-scope and bounty eligible under that primary asset. \n\n  \n\nA mobile application example can be found within our current scope: \n\nAndroid Play Store: com.starbucks.singapore \n\nAssets eligible for bounty referenced directly by this app: \n\nhttps://mobile.starbucks.com.sg \n\n\nA 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. \n\n\n\nThank you for helping keep Starbucks and our users safe! \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Google API Keys\",\"details\":\"Starbucks does not accept submissions for leaked Google API Keys\"}","{\"category\":\"ServiceNow Readable Knowledge Based Articles\",\"details\":\"Starbucks does not accept submissions for ServiceNow KBA's being readable to unauthenticated users.\"}"],"timestamp":"2025-08-13T16:34:38.339Z"},{"id":3758026,"new_policy":"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.  \n\n  \n###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. \n\nStarbucks 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. \n\n  \n\nProgram’s Geographic Regions: \n\n(Parent Program) – North America \nLatin America and Caribbean \nEurope, and Middle East and Africa \nChina \nJapan \nAsia Pacific and India \n\n \n\n \n\n  \n\n\u0026nbsp; \n\n______________________________________________________________________________________________________________________ \n\n  \n\nTable of Contents \n\n\n______________________________________________________________________________________________________________________ \n\n  \n\n  \n\n### Program \n\n1. Legal \n\n3. Program Eligibility \n\n4. Program Rules \n\n  \n\n### Report Submissions \n\n1. What is required when submitting a report? \n\n2. What happens after you submit a report? \n\n3. How do I make my report great? \n\n4. What causes a report to be closed as Informative, Duplicate, N/A, or Spam? \n\n  \n\n### Helpful Hints \n\n### FAQ's \n\n  \n\n\u0026nbsp; \n\n  \n\n______________________________________________________________________________________________________________________ \n\n  \n\nProgram \n\n\n________________________________________ \n\n----------------- \n \n\n\n1. Legal \n\n\nStarbucks 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. \n\n----------------- \n\n\n\n2. Program Eligibility \n\n\n+ You must agree and adhere to the Program Rules and Legal terms as stated in this policy. \n\n+ You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty. \n\n+ You must be available to supply additional information, as needed by our team, to reproduce and triage the issue. \n\n+ Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability. \n\n+ Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible. \n\n+ Starbucks partners (employees) and vendors are not eligible for participation in this program. \n\n----------------- \n\n\n\n3. Program Rules \n\n\n### Do \n\n+ Read and abide by the program policy. \n\n+ 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. \n\n+ Exercise caution when testing to avoid negative impact to customers and the services they depend on. \n\n+ 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. \n\n  \n\n### Do NOT \n\n+ Do not Brute force credentials or guess credentials to gain access to systems. \n\n+ Do not participate in denial of service attacks. \n\n+ Do not upload shells or create a backdoor of any kind. \n\n+ Do not engage in any form of social engineering of Starbucks employees, customers, or vendors. \n\n+ Do not engage or target any Starbucks employee, customer or vendor during your testing. \n\n+ Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own.  \n\n+ 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.  \n\n+ Do not publicly disclose any vulnerabilities proposed to Starbucks. The Starbucks program is strictly confidential. \n\n+ 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. \n\n+ Any violation of these rules can lead to a program ban. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nReport Submissions \n\n______________________________________________________________________________________________________________________ \n\n  \n\n ----------------- \n\n\n1. What is required when submitting a report? \n\n\nProvide the information asked for by the new report form, following the instructions there. Some important considerations include: \n\n+ Title – this should be a quick and clear summary of your issue. \n\n+ Asset – this should match exactly the asset you are reporting, or “Other”. \n\n+ Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity. \n\n+ Weakness – select the most appropriate vulnerability type.  \n\n+ Description – provide all the requested fields. \n\n  \n\n----------------- \n\n\n2. What happens after you submit a report? \n\n\nStarbucks 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. \n\n \n\nStarbucks may close the report as \"Duplicate\", \"Informative\", \"N/A\", \"Spam\", or continue to work with you if more information is needed.  \n\n \n\nOnce 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. \n\n \n\nThe 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. \n\n \"Triage\" means the report is valid \u0026  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\". \n\n \n\n  \n\n  \n\n### Rewards \n\n  \n\nReward amounts are calculated based on the numerical CVSS score assigned to the report. \n\n  \n\nWe 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. \n\n  \n\n+ All bounty amounts will be at the discretion of the Starbucks Bug Bounty team. \n\n+ Reports submitted using methods that violate policy rules will not be eligible for reward. \n\n+ To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.   \n\n+ 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. \n\n+ 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. \n\n+ Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected. \n\n  \n\n  \n\n### Disclosure Requests  \n\n  \n\nAs of October 2024 Starbucks is no longer accepting disclosure requests. All vulnerabilities are strictly confidential. \n\n  \n\n----------------- \n\n\n3. How do I make my report great? \n\nGreat reports lead to quicker resolution and more accurate reward. \n\n+ Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited. \n\n+ Utilize the CVSS v3 calculator to thoughtfully score your report.  \n\n+ Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding.  \n\n+ 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. \n\n+ Include your recommendations to resolve the issue. \n\n+ Be responsive to requests for additional information. \n\n+ Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved. \n\n+ Always be polite and respectful to HackerOne and Starbucks team members. \n\n  \n\nFor more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html \n\n  \n\n  \n\n----------------- \n\n\n4. What causes a report to be closed as Informative, Duplicate, N/A or Spam? \n\n\nThese 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. \n\n  \n\n  \n\n### Spam \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Duplicate \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n### Informative \n\n+ Issues with minimal impact or relating to common security practices that are not prioritized for remediation.   \n\n+ Reports notifying us of broken links or abandoned Social Media accounts. \n\n+ Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls. \n\n+ 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. \n\n+ 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. \n\n  \n\n### N/A \n\n+ Violating program rules defined by HackerOne or those defined within this Starbucks program policy. \n\n+ Reports submitted for assets that clearly do not belong to Starbucks. \n\n+ Reports identifying issues described in our list of Exclusions. \n\n+ Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions. \n\n+ SDTO reports without a working proof of concept confirming you have control over the subdomain in question. \n\n+ 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. \n\n  \n\n_*Exclusions*_ \n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance. * \n\n+ Web cache poisoning where the extent of the impact is denial of service or a misconfiguration with minimal demonstrated risk.\n\n+ Exposed third party API keys that do not demonstrate clear and immediate security risk/impact.\n\n+ Attacks that require a victim user to manually enter scripted and/or malicious commands.\n\n+ Information disclosures/leaks involving online documents or forms that do not pose an immediate security risk.\n\n+ Attacks that are focused on resource exhaustion and/or abusing third party subscription services involving platforms not owned by Starbucks. \n\n+ CORS (Cross Origin Resource Sharing) policy misconfiguration issues that leverage proxied or forwarded traffic.\n\n+ Attacks which require initial navigation to a third party attacker website in order for the attack to succeed.\n\n+ Email bombardment attacks against victim users.\n\n+ SDTO (or reports of similar nature) that do not demonstrate a valid PoC of taking over the target subdomain in question.\n\n+ Reports from automated tools or scans. \n\n+ 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)\n\n+ Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers.  \n\n+ Reports about insecure SSL/TLS configuration. \n\n+ Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing). \n\n+ Presence of publicly accessible login pages. \n\n+ Use of outdated software/library versions. \n\n+ Use of a known-vulnerable library without a description of an exploit specific to our implementation. \n\n+ OPTIONS/TRACE HTTP method enabled. \n\n+ Disclosure of known public files or directories. \n\n+ Presence of autocomplete functionality in form fields. \n\n+ Cookies that lack HTTP Only or Secure settings. \n\n+ Clickjacking and issues only exploitable through clickjacking. \n\n+ Attacks requiring physical access to a user's device or MITM attacks. \n\n+ Attacks dependent upon social engineering of Starbucks employees or vendors. \n\n+ Username enumeration based on login, forgot password, account creation and registration pages. \n\n+ Password or account recovery policies, such as reset link expiration or password complexity. \n\n+ Session management concerns such as session duration, concurrent active sessions or session invalidation triggers. \n\n+ Lack of email address verification during account registration. \n\n+ Enforcement policies for brute force or account lockout. \n\n+ Rate-limiting issues. \n\n+ Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these. \n\n+ Configuration of or missing security headers. \n\n+ Mixed content issues. \n\n+ CSRF on logout. \n\n+ CSRF on forms that are available to anonymous users. \n\n+ Self-XSS and issues exploitable only through Self-XSS. \n\n+ Content spoofing/text injection. \n\n+ Hyperlink injection in emails using forms available to any user.  \n\n+ Lack of obfuscation in mobile apps. \n\n+ Absence of certificate pinning. \n\n+ Lack of jailbreak detection in mobile apps. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nHelpful Hints \n\n______________________________________________________________________________________________________________________ \n\n  \n\n+ Read \u0026 follow the rules. \n\n+ 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.  \n\n+ 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/. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Appropriate Proof of Concepts \n\n+ SQLi\u0026nbsp;\u0026nbsp;- A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you. \n\n+ RCE\u0026nbsp;\u0026nbsp;- A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system. \n\n+ 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.  \n\n+ 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 misconfiguration on a target endpoint.\n\n+ 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. \n______________________________________________________________________________________________________________________ \n\nFAQ's \n______________________________________________________________________________________________________________________ \n\n1.\tCan I get Starbucks swag? \n\n+ Starbucks does not currently offer swag. \n\n2.\tCan Starbucks provide me with a pre-configured test account or Starbucks card(s)? \n\n+ Starbucks does not offer test accounts or test cards. \n\n3.\tAre all APIs / endpoints initiated by an in-scope mobile or web application eligible for bounty? \n\n+ No. Some APIs accessed by Starbucks applications are not developed or maintained by Starbucks application development teams. If reported through our program and we can act to mitigate a vulnerability, we may triage the report as a valid finding, but it would not be eligible for bounty. \n\n  \n\n### How to proceed in this situation: \n\nSet the asset type to the primary application you were testing. Ensure that your write up, includes the specifics for your proof of concept detailing: \n\n  \n\n+ How you tested this \n\n+ Which back end API call(s) had the vulnerability \n\n  \n\nStarbucks will review the report and determine whether it remains in-scope and bounty eligible under that primary asset. \n\n  \n\nA mobile application example can be found within our current scope: \n\nAndroid Play Store: com.starbucks.singapore \n\nAssets eligible for bounty referenced directly by this app: \n\nhttps://mobile.starbucks.com.sg \n\n\nA 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. \n\n\n\nThank you for helping keep Starbucks and our users safe! \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Google API Keys\",\"details\":\"Starbucks does not accept submissions for leaked Google API Keys\"}","{\"category\":\"ServiceNow Readable Knowledge Based Articles\",\"details\":\"Starbucks does not accept submissions for ServiceNow KBA's being readable to unauthenticated users.\"}"],"timestamp":"2025-06-24T19:29:46.461Z"},{"id":3754957,"new_policy":"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.  \n\n  \n###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. \n\nStarbucks 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. \n\n  \n\nProgram’s Geographic Regions: \n\n(Parent Program) – North America \nLatin America and Caribbean \nEurope, and Middle East and Africa \nChina \nJapan \nAsia Pacific and India \n\n \n\n \n\n  \n\n\u0026nbsp; \n\n______________________________________________________________________________________________________________________ \n\n  \n\nTable of Contents \n\n\n______________________________________________________________________________________________________________________ \n\n  \n\n  \n\n### Program \n\n1. Legal \n\n3. Program Eligibility \n\n4. Program Rules \n\n  \n\n### Report Submissions \n\n1. What is required when submitting a report? \n\n2. What happens after you submit a report? \n\n3. How do I make my report great? \n\n4. What causes a report to be closed as Informative, Duplicate, N/A, or Spam? \n\n  \n\n### Helpful Hints \n\n### FAQ's \n\n  \n\n\u0026nbsp; \n\n  \n\n______________________________________________________________________________________________________________________ \n\n  \n\nProgram \n\n\n________________________________________ \n\n----------------- \n \n\n\n1. Legal \n\n\nStarbucks 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. \n\n----------------- \n\n\n\n2. Program Eligibility \n\n\n+ You must agree and adhere to the Program Rules and Legal terms as stated in this policy. \n\n+ You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty. \n\n+ You must be available to supply additional information, as needed by our team, to reproduce and triage the issue. \n\n+ Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability. \n\n+ Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible. \n\n+ Starbucks partners (employees) and vendors are not eligible for participation in this program. \n\n----------------- \n\n\n\n3. Program Rules \n\n\n### Do \n\n+ Read and abide by the program policy. \n\n+ 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. \n\n+ Exercise caution when testing to avoid negative impact to customers and the services they depend on. \n\n+ 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. \n\n  \n\n### Do NOT \n\n+ Do not Brute force credentials or guess credentials to gain access to systems. \n\n+ Do not participate in denial of service attacks. \n\n+ Do not upload shells or create a backdoor of any kind. \n\n+ Do not engage in any form of social engineering of Starbucks employees, customers, or vendors. \n\n+ Do not engage or target any Starbucks employee, customer or vendor during your testing. \n\n+ Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own.  \n\n+ 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.  \n\n+ Do not publicly disclose any vulnerabilities proposed to Starbucks. The Starbucks program is strictly confidential. \n\n+ 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. \n\n+ Any violation of these rules can lead to a program ban. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nReport Submissions \n\n______________________________________________________________________________________________________________________ \n\n  \n\n ----------------- \n\n\n1. What is required when submitting a report? \n\n\nProvide the information asked for by the new report form, following the instructions there. Some important considerations include: \n\n+ Title – this should be a quick and clear summary of your issue. \n\n+ Asset – this should match exactly the asset you are reporting, or “Other”. \n\n+ Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity. \n\n+ Weakness – select the most appropriate vulnerability type.  \n\n+ Description – provide all the requested fields. \n\n  \n\n----------------- \n\n\n2. What happens after you submit a report? \n\n\nStarbucks 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. \n\n \n\nStarbucks may close the report as \"Duplicate\", \"Informative\", \"N/A\", \"Spam\", or continue to work with you if more information is needed.  \n\n \n\nOnce 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. \n\n \n\nThe 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. \n\n \"Triage\" means the report is valid \u0026  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\". \n\n \n\n  \n\n  \n\n### Rewards \n\n  \n\nReward amounts are calculated based on the numerical CVSS score assigned to the report. \n\n  \n\nWe 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. \n\n  \n\n+ All bounty amounts will be at the discretion of the Starbucks Bug Bounty team. \n\n+ Reports submitted using methods that violate policy rules will not be eligible for reward. \n\n+ To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.   \n\n+ 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. \n\n+ 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. \n\n+ Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected. \n\n  \n\n  \n\n### Disclosure Requests  \n\n  \n\nAs of October 2024 Starbucks is no longer accepting disclosure requests. All vulnerabilities are strictly confidential. \n\n  \n\n----------------- \n\n\n3. How do I make my report great? \n\nGreat reports lead to quicker resolution and more accurate reward. \n\n+ Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited. \n\n+ Utilize the CVSS v3 calculator to thoughtfully score your report.  \n\n+ Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding.  \n\n+ 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. \n\n+ Include your recommendations to resolve the issue. \n\n+ Be responsive to requests for additional information. \n\n+ Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved. \n\n+ Always be polite and respectful to HackerOne and Starbucks team members. \n\n  \n\nFor more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html \n\n  \n\n  \n\n----------------- \n\n\n4. What causes a report to be closed as Informative, Duplicate, N/A or Spam? \n\n\nThese 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. \n\n  \n\n  \n\n### Spam \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Duplicate \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n### Informative \n\n+ Issues with minimal impact or relating to common security practices that are not prioritized for remediation.   \n\n+ Reports notifying us of broken links or abandoned Social Media accounts. \n\n+ Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls. \n\n+ 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. \n\n+ 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. \n\n  \n\n### N/A \n\n+ Violating program rules defined by HackerOne or those defined within this Starbucks program policy. \n\n+ Reports submitted for assets that clearly do not belong to Starbucks. \n\n+ Reports identifying issues described in our list of Exclusions. \n\n+ Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions. \n\n+ SDTO reports without a working proof of concept confirming you have control over the subdomain in question. \n\n+ 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. \n\n  \n\n_*Exclusions*_ \n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance.* \n\n+ Web cache poisoning where the extent of the impact is denial of service or a misconfiguration with minimal demonstrated risk.\n\n+ Exposed third party API keys that do not demonstrate clear and immediate security risk/impact.\n\n+ Attacks that require a victim user to manually enter scripted and/or malicious commands.\n\n+ Information disclosures/leaks involving online documents or forms that do not pose an immediate security risk.\n\n+ Attacks that are focused on resource exhaustion and/or abusing third party subscription services involving platforms not owned by Starbucks. \n\n+ CORS (Cross Origin Resource Sharing) policy misconfiguration issues that leverage proxied or forwarded traffic.\n\n+ Attacks which require initial navigation to a third party attacker website in order for the attack to succeed.\n\n+ Email bombardment attacks against victim users.\n\n+ SDTO (or reports of similar nature) that do not demonstrate a valid PoC of taking over the target subdomain in question.\n\n+ Reports from automated tools or scans. \n\n+ Reports of credentials exposed by other data breaches / known credential lists. \n\n+ Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers.  \n\n+ Reports about insecure SSL/TLS configuration. \n\n+ Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing). \n\n+ Presence of publicly accessible login pages. \n\n+ Use of outdated software/library versions. \n\n+ Use of a known-vulnerable library without a description of an exploit specific to our implementation. \n\n+ OPTIONS/TRACE HTTP method enabled. \n\n+ Disclosure of known public files or directories. \n\n+ Presence of autocomplete functionality in form fields. \n\n+ Cookies that lack HTTP Only or Secure settings. \n\n+ Clickjacking and issues only exploitable through clickjacking. \n\n+ Attacks requiring physical access to a user's device or MITM attacks. \n\n+ Attacks dependent upon social engineering of Starbucks employees or vendors. \n\n+ Username enumeration based on login, forgot password, account creation and registration pages. \n\n+ Password or account recovery policies, such as reset link expiration or password complexity. \n\n+ Session management concerns such as session duration, concurrent active sessions or session invalidation triggers. \n\n+ Lack of email address verification during account registration. \n\n+ Enforcement policies for brute force or account lockout. \n\n+ Rate-limiting issues. \n\n+ Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these. \n\n+ Configuration of or missing security headers. \n\n+ Mixed content issues. \n\n+ CSRF on logout. \n\n+ CSRF on forms that are available to anonymous users. \n\n+ Self-XSS and issues exploitable only through Self-XSS. \n\n+ Content spoofing/text injection. \n\n+ Hyperlink injection in emails using forms available to any user.  \n\n+ Lack of obfuscation in mobile apps. \n\n+ Absence of certificate pinning. \n\n+ Lack of jailbreak detection in mobile apps. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nHelpful Hints \n\n______________________________________________________________________________________________________________________ \n\n  \n\n+ Read \u0026 follow the rules. \n\n+ 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.  \n\n+ 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/. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Appropriate Proof of Concepts \n\n+ SQLi\u0026nbsp;\u0026nbsp;- A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you. \n\n+ RCE\u0026nbsp;\u0026nbsp;- A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system. \n\n+ 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.  \n\n+ 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 misconfiguration on a target endpoint.\n______________________________________________________________________________________________________________________ \n\nFAQ's \n______________________________________________________________________________________________________________________ \n\n1.\tCan I get Starbucks swag? \n\n+ Starbucks does not currently offer swag. \n\n2.\tCan Starbucks provide me with a pre-configured test account or Starbucks card(s)? \n\n+ Starbucks does not offer test accounts or test cards. \n\n3.\tAre all APIs / endpoints initiated by an in-scope mobile or web application eligible for bounty? \n\n+ No. Some APIs accessed by Starbucks applications are not developed or maintained by Starbucks application development teams. If reported through our program and we can act to mitigate a vulnerability, we may triage the report as a valid finding, but it would not be eligible for bounty. \n\n  \n\n### How to proceed in this situation: \n\nSet the asset type to the primary application you were testing. Ensure that your write up, includes the specifics for your proof of concept detailing: \n\n  \n\n+ How you tested this \n\n+ Which back end API call(s) had the vulnerability \n\n  \n\nStarbucks will review the report and determine whether it remains in-scope and bounty eligible under that primary asset. \n\n  \n\nA mobile application example can be found within our current scope: \n\nAndroid Play Store: com.starbucks.singapore \n\nAssets eligible for bounty referenced directly by this app: \n\nhttps://mobile.starbucks.com.sg \n\n\nA 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. \n\n\n\nThank you for helping keep Starbucks and our users safe! \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Google API Keys\",\"details\":\"Starbucks does not accept submissions for leaked Google API Keys\"}","{\"category\":\"ServiceNow Readable Knowledge Based Articles\",\"details\":\"Starbucks does not accept submissions for ServiceNow KBA's being readable to unauthenticated users.\"}"],"timestamp":"2025-05-06T20:17:39.787Z"},{"id":3752104,"new_policy":"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.  \n\n  \n###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. \n\nStarbucks 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. \n\n  \n\nProgram’s Geographic Regions: \n\n(Parent Program) – North America \nLatin America and Caribbean \nEurope, and Middle East and Africa \nChina \nJapan \nAsia Pacific and India \n\n \n\n \n\n  \n\n\u0026nbsp; \n\n______________________________________________________________________________________________________________________ \n\n  \n\nTable of Contents \n\n\n______________________________________________________________________________________________________________________ \n\n  \n\n  \n\n### Program \n\n1. Legal \n\n3. Program Eligibility \n\n4. Program Rules \n\n  \n\n### Report Submissions \n\n1. What is required when submitting a report? \n\n2. What happens after you submit a report? \n\n3. How do I make my report great? \n\n4. What causes a report to be closed as Informative, Duplicate, N/A, or Spam? \n\n  \n\n### Helpful Hints \n\n### FAQ's \n\n  \n\n\u0026nbsp; \n\n  \n\n______________________________________________________________________________________________________________________ \n\n  \n\nProgram \n\n\n________________________________________ \n\n----------------- \n \n\n\n1. Legal \n\n\nStarbucks 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. \n\n----------------- \n\n\n\n2. Program Eligibility \n\n\n+ You must agree and adhere to the Program Rules and Legal terms as stated in this policy. \n\n+ You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty. \n\n+ You must be available to supply additional information, as needed by our team, to reproduce and triage the issue. \n\n+ Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability. \n\n+ Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible. \n\n+ Starbucks partners (employees) and vendors are not eligible for participation in this program. \n\n----------------- \n\n\n\n3. Program Rules \n\n\n### Do \n\n+ Read and abide by the program policy. \n\n+ 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. \n\n+ Exercise caution when testing to avoid negative impact to customers and the services they depend on. \n\n+ 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. \n\n  \n\n### Do NOT \n\n+ Do not Brute force credentials or guess credentials to gain access to systems. \n\n+ Do not participate in denial of service attacks. \n\n+ Do not upload shells or create a backdoor of any kind. \n\n+ Do not engage in any form of social engineering of Starbucks employees, customers, or vendors. \n\n+ Do not engage or target any Starbucks employee, customer or vendor during your testing. \n\n+ Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own.  \n\n+ 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.  \n\n+ Do not publicly disclose any vulnerabilities proposed to Starbucks. The Starbucks program is strictly confidential. \n\n+ 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. \n\n+ Any violation of these rules can lead to a program ban. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nReport Submissions \n\n______________________________________________________________________________________________________________________ \n\n  \n\n ----------------- \n\n\n1. What is required when submitting a report? \n\n\nProvide the information asked for by the new report form, following the instructions there. Some important considerations include: \n\n+ Title – this should be a quick and clear summary of your issue. \n\n+ Asset – this should match exactly the asset you are reporting, or “Other”. \n\n+ Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity. \n\n+ Weakness – select the most appropriate vulnerability type.  \n\n+ Description – provide all the requested fields. \n\n  \n\n----------------- \n\n\n2. What happens after you submit a report? \n\n\nStarbucks 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. \n\n \n\nStarbucks may close the report as \"Duplicate\", \"Informative\", \"N/A\", \"Spam\", or continue to work with you if more information is needed.  \n\n \n\nOnce 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. \n\n \n\nThe 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. \n\n \"Triage\" means the report is valid \u0026  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\". \n\n \n\n  \n\n  \n\n### Rewards \n\n  \n\nReward amounts are calculated based on the numerical CVSS score assigned to the report. \n\n  \n\nWe 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. \n\n  \n\n+ All bounty amounts will be at the discretion of the Starbucks Bug Bounty team. \n\n+ Reports submitted using methods that violate policy rules will not be eligible for reward. \n\n+ To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.   \n\n+ 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. \n\n+ 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. \n\n+ Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected. \n\n  \n\n  \n\n### Disclosure Requests  \n\n  \n\nAs of October 2024 Starbucks is no longer accepting disclosure requests. All vulnerabilities are strictly confidential. \n\n  \n\n----------------- \n\n\n3. How do I make my report great? \n\nGreat reports lead to quicker resolution and more accurate reward. \n\n+ Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited. \n\n+ Utilize the CVSS v3 calculator to thoughtfully score your report.  \n\n+ Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding.  \n\n+ 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. \n\n+ Include your recommendations to resolve the issue. \n\n+ Be responsive to requests for additional information. \n\n+ Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved. \n\n+ Always be polite and respectful to HackerOne and Starbucks team members. \n\n  \n\nFor more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html \n\n  \n\n  \n\n----------------- \n\n\n4. What causes a report to be closed as Informative, Duplicate, N/A or Spam? \n\n\nThese 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. \n\n  \n\n  \n\n### Spam \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Duplicate \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n### Informative \n\n+ Issues with minimal impact or relating to common security practices that are not prioritized for remediation.   \n\n+ Reports notifying us of broken links or abandoned Social Media accounts. \n\n+ Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls. \n\n+ 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. \n\n+ 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. \n\n  \n\n### N/A \n\n+ Violating program rules defined by HackerOne or those defined within this Starbucks program policy. \n\n+ Reports submitted for assets that clearly do not belong to Starbucks. \n\n+ Reports identifying issues described in our list of Exclusions. \n\n+ Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions. \n\n+ SDTO reports without a working proof of concept confirming you have control over the subdomain in question. \n\n+ 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. \n\n  \n\n_*Exclusions*_ \n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance.* \n\n+ Exposed third party API keys that do not demonstrate clear and immediate security risk/impact.\n\n+ Attacks that require a victim user to manually enter scripted and/or malicious commands.\n\n+ Information disclosures/leaks involving online documents or forms that do not pose an immediate security risk.\n\n+ Attacks that are focused on resource exhaustion and/or abusing third party subscription services involving platforms not owned by Starbucks. \n\n+ CORS (Cross Origin Resource Sharing) policy misconfiguration issues that leverage proxied or forwarded traffic.\n\n+ Attacks which require initial navigation to a third party attacker website in order for the attack to succeed.\n\n+ Email bombardment attacks against victim users.\n\n+ SDTO (or reports of similar nature) that do not demonstrate a valid PoC of taking over the target subdomain in question.\n\n+ Reports from automated tools or scans. \n\n+ Reports of credentials exposed by other data breaches / known credential lists. \n\n+ Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers.  \n\n+ Reports about insecure SSL/TLS configuration. \n\n+ Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing). \n\n+ Presence of publicly accessible login pages. \n\n+ Use of outdated software/library versions. \n\n+ Use of a known-vulnerable library without a description of an exploit specific to our implementation. \n\n+ OPTIONS/TRACE HTTP method enabled. \n\n+ Disclosure of known public files or directories. \n\n+ Presence of autocomplete functionality in form fields. \n\n+ Cookies that lack HTTP Only or Secure settings. \n\n+ Clickjacking and issues only exploitable through clickjacking. \n\n+ Attacks requiring physical access to a user's device or MITM attacks. \n\n+ Attacks dependent upon social engineering of Starbucks employees or vendors. \n\n+ Username enumeration based on login, forgot password, account creation and registration pages. \n\n+ Password or account recovery policies, such as reset link expiration or password complexity. \n\n+ Session management concerns such as session duration, concurrent active sessions or session invalidation triggers. \n\n+ Lack of email address verification during account registration. \n\n+ Enforcement policies for brute force or account lockout. \n\n+ Rate-limiting issues. \n\n+ Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these. \n\n+ Configuration of or missing security headers. \n\n+ Mixed content issues. \n\n+ CSRF on logout. \n\n+ CSRF on forms that are available to anonymous users. \n\n+ Self-XSS and issues exploitable only through Self-XSS. \n\n+ Content spoofing/text injection. \n\n+ Hyperlink injection in emails using forms available to any user.  \n\n+ Lack of obfuscation in mobile apps. \n\n+ Absence of certificate pinning. \n\n+ Lack of jailbreak detection in mobile apps. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nHelpful Hints \n\n______________________________________________________________________________________________________________________ \n\n  \n\n+ Read \u0026 follow the rules. \n\n+ 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.  \n\n+ 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/. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Appropriate Proof of Concepts \n\n+ SQLi\u0026nbsp;\u0026nbsp;- A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you. \n\n+ RCE\u0026nbsp;\u0026nbsp;- A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system. \n\n+ 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.  \n______________________________________________________________________________________________________________________ \n\nFAQ's \n______________________________________________________________________________________________________________________ \n\n1.\tCan I get Starbucks swag? \n\n+ Starbucks does not currently offer swag. \n\n2.\tCan Starbucks provide me with a pre-configured test account or Starbucks card(s)? \n\n+ Starbucks does not offer test accounts or test cards. \n\n3.\tAre all APIs / endpoints initiated by an in-scope mobile or web application eligible for bounty? \n\n+ No. Some APIs accessed by Starbucks applications are not developed or maintained by Starbucks application development teams. If reported through our program and we can act to mitigate a vulnerability, we may triage the report as a valid finding, but it would not be eligible for bounty. \n\n  \n\n### How to proceed in this situation: \n\nSet the asset type to the primary application you were testing. Ensure that your write up, includes the specifics for your proof of concept detailing: \n\n  \n\n+ How you tested this \n\n+ Which back end API call(s) had the vulnerability \n\n  \n\nStarbucks will review the report and determine whether it remains in-scope and bounty eligible under that primary asset. \n\n  \n\nA mobile application example can be found within our current scope: \n\nAndroid Play Store: com.starbucks.singapore \n\nAssets eligible for bounty referenced directly by this app: \n\nhttps://mobile.starbucks.com.sg \n\n\nA 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. \n\n\n\nThank you for helping keep Starbucks and our users safe! \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Google API Keys\",\"details\":\"Starbucks does not accept submissions for leaked Google API Keys\"}","{\"category\":\"ServiceNow Readable Knowledge Based Articles\",\"details\":\"Starbucks does not accept submissions for ServiceNow KBA's being readable to unauthenticated users.\"}"],"timestamp":"2025-03-19T19:03:27.685Z"},{"id":3743909,"new_policy":"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.  \n\n  \n###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. \n\nStarbucks 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. \n\n  \n\nProgram’s Geographic Regions: \n\n(Parent Program) – North America \nLatin America and Caribbean \nEurope, and Middle East and Africa \nChina \nJapan \nAsia Pacific and India \n\n \n\n \n\n  \n\n\u0026nbsp; \n\n______________________________________________________________________________________________________________________ \n\n  \n\nTable of Contents \n\n\n______________________________________________________________________________________________________________________ \n\n  \n\n  \n\n### Program \n\n1. Legal \n\n3. Program Eligibility \n\n4. Program Rules \n\n  \n\n### Report Submissions \n\n1. What is required when submitting a report? \n\n2. What happens after you submit a report? \n\n3. How do I make my report great? \n\n4. What causes a report to be closed as Informative, Duplicate, N/A, or Spam? \n\n  \n\n### Helpful Hints \n\n### FAQ's \n\n  \n\n\u0026nbsp; \n\n  \n\n______________________________________________________________________________________________________________________ \n\n  \n\nProgram \n\n\n________________________________________ \n\n----------------- \n \n\n\n1. Legal \n\n\nStarbucks 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. \n\n----------------- \n\n\n\n2. Program Eligibility \n\n\n+ You must agree and adhere to the Program Rules and Legal terms as stated in this policy. \n\n+ You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty. \n\n+ You must be available to supply additional information, as needed by our team, to reproduce and triage the issue. \n\n+ Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability. \n\n+ Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible. \n\n+ Starbucks partners (employees) and vendors are not eligible for participation in this program. \n\n----------------- \n\n\n\n3. Program Rules \n\n\n### Do \n\n+ Read and abide by the program policy. \n\n+ 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. \n\n+ Exercise caution when testing to avoid negative impact to customers and the services they depend on. \n\n+ 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. \n\n  \n\n### Do NOT \n\n+ Do not Brute force credentials or guess credentials to gain access to systems. \n\n+ Do not participate in denial of service attacks. \n\n+ Do not upload shells or create a backdoor of any kind. \n\n+ Do not engage in any form of social engineering of Starbucks employees, customers, or vendors. \n\n+ Do not engage or target any Starbucks employee, customer or vendor during your testing. \n\n+ Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own.  \n\n+ 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.  \n\n+ Do not publicly disclose any vulnerabilities proposed to Starbucks. The Starbucks program is strictly confidential. \n\n+ 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. \n\n+ Any violation of these rules can lead to a prgram ban. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nReport Submissions \n\n______________________________________________________________________________________________________________________ \n\n  \n\n ----------------- \n\n\n1. What is required when submitting a report? \n\n\nProvide the information asked for by the new report form, following the instructions there. Some important considerations include: \n\n+ Title – this should be a quick and clear summary of your issue. \n\n+ Asset – this should match exactly the asset you are reporting, or “Other”. \n\n+ Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity. \n\n+ Weakness – select the most appropriate vulnerability type.  \n\n+ Description – provide all the requested fields. \n\n  \n\n----------------- \n\n\n2. What happens after you submit a report? \n\n\nStarbucks 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. \n\n \n\nStarbucks may close the report as \"Duplicate\", \"Informative\", \"N/A\", \"Spam\", or continue to work with you if more information is needed.  \n\n \n\nOnce 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. \n\n \n\nThe 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. \n\n \"Triage\" means the report is valid \u0026  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\". \n\n \n\n  \n\n  \n\n### Rewards \n\n  \n\nReward amounts are calculated based on the numerical CVSS score assigned to the report. \n\n  \n\nWe 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. \n\n  \n\n+ All bounty amounts will be at the discretion of the Starbucks Bug Bounty team. \n\n+ Reports submitted using methods that violate policy rules will not be eligible for reward. \n\n+ To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.   \n\n+ 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. \n\n+ 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. \n\n+ Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected. \n\n  \n\n  \n\n### Disclosure Requests  \n\n  \n\nAs of October 2024 Starbucks is no longer accepting disclosure requests. All vulnerabilities are strictly confidential. \n\n  \n\n----------------- \n\n\n3. How do I make my report great? \n\nGreat reports lead to quicker resolution and more accurate reward. \n\n+ Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited. \n\n+ Utilize the CVSS v3 calculator to thoughtfully score your report.  \n\n+ Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding.  \n\n+ 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. \n\n+ Include your recommendations to resolve the issue. \n\n+ Be responsive to requests for additional information. \n\n+ Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved. \n\n+ Always be polite and respectful to HackerOne and Starbucks team members. \n\n  \n\nFor more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html \n\n  \n\n  \n\n----------------- \n\n\n4. What causes a report to be closed as Informative, Duplicate, N/A or Spam? \n\n\nThese 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. \n\n  \n\n  \n\n### Spam \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Duplicate \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n### Informative \n\n+ Issues with minimal impact or relating to common security practices that are not prioritized for remediation.   \n\n+ Reports notifying us of broken links or abandoned Social Media accounts. \n\n+ Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls. \n\n+ 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. \n\n+ 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. \n\n  \n\n### N/A \n\n+ Violating program rules defined by HackerOne or those defined within this Starbucks program policy. \n\n+ Reports submitted for assets that clearly do not belong to Starbucks. \n\n+ Reports identifying issues described in our list of Exclusions. \n\n+ Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions. \n\n+ SDTO reports without a working proof of concept confirming you have control over the subdomain in question. \n\n+ 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. \n\n  \n\n_*Exclusions*_ \n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance.* \n\n+ Reports from automated tools or scans. \n\n+ Reports of credentials exposed by other data breaches / known credential lists. \n\n+ Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers.  \n\n+ Reports about insecure SSL/TLS configuration. \n\n+ Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing). \n\n+ Presence of publicly accessible login pages. \n\n+ Use of outdated software/library versions. \n\n+ Use of a known-vulnerable library without a description of an exploit specific to our implementation. \n\n+ OPTIONS/TRACE HTTP method enabled. \n\n+ Disclosure of known public files or directories. \n\n+ Presence of autocomplete functionality in form fields. \n\n+ Cookies that lack HTTP Only or Secure settings. \n\n+ Clickjacking and issues only exploitable through clickjacking. \n\n+ Attacks requiring physical access to a user's device or MITM attacks. \n\n+ Attacks dependent upon social engineering of Starbucks employees or vendors. \n\n+ Username enumeration based on login, forgot password, account creation and registration pages. \n\n+ Password or account recovery policies, such as reset link expiration or password complexity. \n\n+ Session management concerns such as session duration, concurrent active sessions or session invalidation triggers. \n\n+ Lack of email address verification during account registration. \n\n+ Enforcement policies for brute force or account lockout. \n\n+ Rate-limiting issues. \n\n+ Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these. \n\n+ Configuration of or missing security headers. \n\n+ Mixed content issues. \n\n+ CSRF on logout. \n\n+ CSRF on forms that are available to anonymous users. \n\n+ Self-XSS and issues exploitable only through Self-XSS. \n\n+ Content spoofing/text injection. \n\n+ Hyperlink injection in emails using forms available to any user.  \n\n+ Lack of obfuscation in mobile apps. \n\n+ Absence of certificate pinning. \n\n+ Lack of jailbreak detection in mobile apps. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nHelpful Hints \n\n______________________________________________________________________________________________________________________ \n\n  \n\n+ Read \u0026 follow the rules. \n\n+ 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.  \n\n+ 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/. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Appropriate Proof of Concepts \n\n+ SQLi\u0026nbsp;\u0026nbsp;- A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you. \n\n+ RCE\u0026nbsp;\u0026nbsp;- A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system. \n\n+ 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.  \n______________________________________________________________________________________________________________________ \n\nFAQ's \n______________________________________________________________________________________________________________________ \n\n1.\tCan I get Starbucks swag? \n\n+ Starbucks does not currently offer swag. \n\n2.\tCan Starbucks provide me with a pre-configured test account or Starbucks card(s)? \n\n+ Starbucks does not offer test accounts or test cards. \n\n3.\tAre all APIs / endpoints initiated by an in-scope mobile or web application eligible for bounty? \n\n+ No. Some APIs accessed by Starbucks applications are not developed or maintained by Starbucks application development teams. If reported through our program and we can act to mitigate a vulnerability, we may triage the report as a valid finding, but it would not be eligible for bounty. \n\n  \n\n### How to proceed in this situation: \n\nSet the asset type to the primary application you were testing. Ensure that your write up, includes the specifics for your proof of concept detailing: \n\n  \n\n+ How you tested this \n\n+ Which back end API call(s) had the vulnerability \n\n  \n\nStarbucks will review the report and determine whether it remains in-scope and bounty eligible under that primary asset. \n\n  \n\nA mobile application example can be found within our current scope: \n\nAndroid Play Store: com.starbucks.singapore \n\nAssets eligible for bounty referenced directly by this app: \n\nhttps://mobile.starbucks.com.sg \n\n\nA 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. \n\n\n\nThank you for helping keep Starbucks and our users safe! \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Google API Keys\",\"details\":\"Starbucks does not accept submissions for leaked Google API Keys\"}","{\"category\":\"ServiceNow Readable Knowledge Based Articles\",\"details\":\"Starbucks does not accept submissions for ServiceNow KBA's being readable to unauthenticated users.\"}"],"timestamp":"2024-11-06T22:12:46.265Z"},{"id":3743905,"new_policy":"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.  \n\n  \n###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. \n\nStarbucks 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. \n\n  \n\nProgram’s Geographic Regions: \n\n(Parent Program) – North America \nLatin America and Caribbean \nEurope, and Middle East and Africa \nChina \nJapan \n Asia Pacific and India \n\n \n\n \n\n  \n\n\u0026nbsp; \n\n______________________________________________________________________________________________________________________ \n\n  \n\nTable of Contents \n\n\n______________________________________________________________________________________________________________________ \n\n  \n\n  \n\n### Program \n\n1. Legal \n\n3. Program Eligibility \n\n4. Program Rules \n\n  \n\n### Report Submissions \n\n1. What is required when submitting a report? \n\n2. What happens after you submit a report? \n\n3. How do I make my report great? \n\n4. What causes a report to be closed as Informative, Duplicate, N/A, or Spam? \n\n  \n\n### Helpful Hints \n\n### FAQ's \n\n  \n\n\u0026nbsp; \n\n  \n\n______________________________________________________________________________________________________________________ \n\n  \n\nProgram \n\n\n________________________________________ \n\n----------------- \n \n\n1. Legal \n\n\nStarbucks 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. \n\n----------------- \n\n\n2. Program Eligibility \n\n\n+ You must agree and adhere to the Program Rules and Legal terms as stated in this policy. \n\n+ You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty. \n\n+ You must be available to supply additional information, as needed by our team, to reproduce and triage the issue. \n\n+ Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability. \n\n+ Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible. \n\n+ Starbucks partners (employees) and vendors are not eligible for participation in this program. \n\n----------------- \n\n\n3. Program Rules \n\n\n### Do \n\n+ Read and abide by the program policy. \n\n+ 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. \n\n+ Exercise caution when testing to avoid negative impact to customers and the services they depend on. \n\n+ 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. \n\n  \n\n### Do NOT \n\n+ Do not Brute force credentials or guess credentials to gain access to systems. \n\n+ Do not participate in denial of service attacks. \n\n+ Do not upload shells or create a backdoor of any kind. \n\n+ Do not engage in any form of social engineering of Starbucks employees, customers, or vendors. \n\n+ Do not engage or target any Starbucks employee, customer or vendor during your testing. \n\n+ Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own.  \n\n+ 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.  \n\n+ Do not publicly disclose any vulnerabilities proposed to Starbucks. The Starbucks program is strictly confidential. \n\n+ 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. \n\n+ Any violation of these rules can lead to a prgram ban. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nReport Submissions \n\n______________________________________________________________________________________________________________________ \n\n  \n\n ----------------- \n\n1. What is required when submitting a report? \n\n\nProvide the information asked for by the new report form, following the instructions there. Some important considerations include: \n\n+ Title – this should be a quick and clear summary of your issue. \n\n+ Asset – this should match exactly the asset you are reporting, or “Other”. \n\n+ Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity. \n\n+ Weakness – select the most appropriate vulnerability type.  \n\n+ Description – provide all the requested fields. \n\n  \n\n----------------- \n\n2. What happens after you submit a report? \n\n\nStarbucks 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. \n\n \n\nStarbucks may close the report as \"Duplicate\", \"Informative\", \"N/A\", \"Spam\", or continue to work with you if more information is needed.  \n\n \n\nOnce 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. \n\n \n\nThe 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. \n\n \"Triage\" means the report is valid \u0026  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\". \n\n \n\n  \n\n  \n\n### Rewards \n\n  \n\nReward amounts are calculated based on the numerical CVSS score assigned to the report. \n\n  \n\nWe 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. \n\n  \n\n+ All bounty amounts will be at the discretion of the Starbucks Bug Bounty team. \n\n+ Reports submitted using methods that violate policy rules will not be eligible for reward. \n\n+ To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.   \n\n+ 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. \n\n+ 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. \n\n+ Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected. \n\n  \n\n  \n\n### Disclosure Requests  \n\n  \n\nAs of October 2024 Starbucks is no longer accepting disclosure requests. All vulnerabilities are strictly confidential. \n\n  \n\n----------------- \n\n3. How do I make my report great? \n\nGreat reports lead to quicker resolution and more accurate reward. \n\n+ Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited. \n\n+ Utilize the CVSS v3 calculator to thoughtfully score your report.  \n\n+ Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding.  \n\n+ 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. \n\n+ Include your recommendations to resolve the issue. \n\n+ Be responsive to requests for additional information. \n\n+ Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved. \n\n+ Always be polite and respectful to HackerOne and Starbucks team members. \n\n  \n\nFor more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html \n\n  \n\n  \n\n----------------- \n\n4. What causes a report to be closed as Informative, Duplicate, N/A or Spam? \n\n\nThese 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. \n\n  \n\n  \n\n### Spam \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Duplicate \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n### Informative \n\n+ Issues with minimal impact or relating to common security practices that are not prioritized for remediation.   \n\n+ Reports notifying us of broken links or abandoned Social Media accounts. \n\n+ Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls. \n\n+ 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. \n\n+ 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. \n\n  \n\n### N/A \n\n+ Violating program rules defined by HackerOne or those defined within this Starbucks program policy. \n\n+ Reports submitted for assets that clearly do not belong to Starbucks. \n\n+ Reports identifying issues described in our list of Exclusions. \n\n+ Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions. \n\n+ SDTO reports without a working proof of concept confirming you have control over the subdomain in question. \n\n+ 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. \n\n  \n\n_*Exclusions*_ \n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance.* \n\n+ Reports from automated tools or scans. \n\n+ Reports of credentials exposed by other data breaches / known credential lists. \n\n+ Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers.  \n\n+ Reports about insecure SSL/TLS configuration. \n\n+ Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing). \n\n+ Presence of publicly accessible login pages. \n\n+ Use of outdated software/library versions. \n\n+ Use of a known-vulnerable library without a description of an exploit specific to our implementation. \n\n+ OPTIONS/TRACE HTTP method enabled. \n\n+ Disclosure of known public files or directories. \n\n+ Presence of autocomplete functionality in form fields. \n\n+ Cookies that lack HTTP Only or Secure settings. \n\n+ Clickjacking and issues only exploitable through clickjacking. \n\n+ Attacks requiring physical access to a user's device or MITM attacks. \n\n+ Attacks dependent upon social engineering of Starbucks employees or vendors. \n\n+ Username enumeration based on login, forgot password, account creation and registration pages. \n\n+ Password or account recovery policies, such as reset link expiration or password complexity. \n\n+ Session management concerns such as session duration, concurrent active sessions or session invalidation triggers. \n\n+ Lack of email address verification during account registration. \n\n+ Enforcement policies for brute force or account lockout. \n\n+ Rate-limiting issues. \n\n+ Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these. \n\n+ Configuration of or missing security headers. \n\n+ Mixed content issues. \n\n+ CSRF on logout. \n\n+ CSRF on forms that are available to anonymous users. \n\n+ Self-XSS and issues exploitable only through Self-XSS. \n\n+ Content spoofing/text injection. \n\n+ Hyperlink injection in emails using forms available to any user.  \n\n+ Lack of obfuscation in mobile apps. \n\n+ Absence of certificate pinning. \n\n+ Lack of jailbreak detection in mobile apps. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nHelpful Hints \n\n______________________________________________________________________________________________________________________ \n\n  \n\n+ Read \u0026 follow the rules. \n\n+ 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.  \n\n+ 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/. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Appropriate Proof of Concepts \n\n+ SQLi\u0026nbsp;\u0026nbsp;- A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you. \n\n+ RCE\u0026nbsp;\u0026nbsp;- A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system. \n\n+ 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.  \n______________________________________________________________________________________________________________________ \n\nFAQ's \n______________________________________________________________________________________________________________________ \n\n1.\tCan I get Starbucks swag? \n\n+ Starbucks does not currently offer swag. \n\n2.\tCan Starbucks provide me with a pre-configured test account or Starbucks card(s)? \n\n+ Starbucks does not offer test accounts or test cards. \n\n3.\tAre all APIs / endpoints initiated by an in-scope mobile or web application eligible for bounty? \n\n+ No. Some APIs accessed by Starbucks applications are not developed or maintained by Starbucks application development teams. If reported through our program and we can act to mitigate a vulnerability, we may triage the report as a valid finding, but it would not be eligible for bounty. \n\n  \n\n### How to proceed in this situation: \n\nSet the asset type to the primary application you were testing. Ensure that your write up, includes the specifics for your proof of concept detailing: \n\n  \n\n+ How you tested this \n\n+ Which back end API call(s) had the vulnerability \n\n  \n\nStarbucks will review the report and determine whether it remains in-scope and bounty eligible under that primary asset. \n\n  \n\nA mobile application example can be found within our current scope: \n\nAndroid Play Store: com.starbucks.singapore \n\nAssets eligible for bounty referenced directly by this app: \n\nhttps://mobile.starbucks.com.sg \n\n\nA 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. \n\n\n\nThank you for helping keep Starbucks and our users safe! \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Google API Keys\",\"details\":\"Starbucks does not accept submissions for leaked Google API Keys\"}","{\"category\":\"ServiceNow Readable Knowledge Based Articles\",\"details\":\"Starbucks does not accept submissions for ServiceNow KBA's being readable to unauthenticated users.\"}"],"timestamp":"2024-11-06T22:08:01.586Z"},{"id":3743904,"new_policy":"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.  \n\n  \n###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. \n\nStarbucks 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. \n\n  \n\nProgram’s Geographic Regions: \n\n(Parent Program) – North America \nLatin America and Caribbean \nEurope, and Middle East and Africa \nChina \nJapan \n Asia Pacific and India \n\n \n\n \n\n  \n\n\u0026nbsp; \n\n______________________________________________________________________________________________________________________ \n\n  \n\nTable of Contents \n\n\n______________________________________________________________________________________________________________________ \n\n  \n\n  \n\n### Program \n\n1. Legal \n\n3. Program Eligibility \n\n4. Program Rules \n\n  \n\n### Report Submissions \n\n1. What is required when submitting a report? \n\n2. What happens after you submit a report? \n\n3. How do I make my report great? \n\n4. What causes a report to be closed as Informative, Duplicate, N/A, or Spam? \n\n  \n\n### Helpful Hints \n\n### FAQ's \n\n  \n\n\u0026nbsp; \n\n  \n\n______________________________________________________________________________________________________________________ \n\n  \n\nProgram \n\n\n________________________________________ \n\n  \n\n1. Legal \n\n----------------- \n\nStarbucks 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. \n\n  \n\n2. Program Eligibility \n\n----------------- \n\n+ You must agree and adhere to the Program Rules and Legal terms as stated in this policy. \n\n+ You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty. \n\n+ You must be available to supply additional information, as needed by our team, to reproduce and triage the issue. \n\n+ Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability. \n\n+ Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible. \n\n+ Starbucks partners (employees) and vendors are not eligible for participation in this program. \n\n  \n\n3. Program Rules \n\n----------------- \n\n### Do \n\n+ Read and abide by the program policy. \n\n+ 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. \n\n+ Exercise caution when testing to avoid negative impact to customers and the services they depend on. \n\n+ 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. \n\n  \n\n### Do NOT \n\n+ Do not Brute force credentials or guess credentials to gain access to systems. \n\n+ Do not participate in denial of service attacks. \n\n+ Do not upload shells or create a backdoor of any kind. \n\n+ Do not engage in any form of social engineering of Starbucks employees, customers, or vendors. \n\n+ Do not engage or target any Starbucks employee, customer or vendor during your testing. \n\n+ Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own.  \n\n+ 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.  \n\n+ Do not publicly disclose any vulnerabilities proposed to Starbucks. The Starbucks program is strictly confidential. \n\n+ 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. \n\n+ Any violation of these rules can lead to a prgram ban. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nReport Submissions \n\n______________________________________________________________________________________________________________________ \n\n  \n\n  \n\n1. What is required when submitting a report? \n\n----------------- \n\nProvide the information asked for by the new report form, following the instructions there. Some important considerations include: \n\n+ Title – this should be a quick and clear summary of your issue. \n\n+ Asset – this should match exactly the asset you are reporting, or “Other”. \n\n+ Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity. \n\n+ Weakness – select the most appropriate vulnerability type.  \n\n+ Description – provide all the requested fields. \n\n  \n\n  \n\n2. What happens after you submit a report? \n\n-----------------   \n\nStarbucks 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. \n\n \n\nStarbucks may close the report as \"Duplicate\", \"Informative\", \"N/A\", \"Spam\", or continue to work with you if more information is needed.  \n\n \n\nOnce 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. \n\n \n\nThe 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. \n\n \"Triage\" means the report is valid \u0026  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\". \n\n \n\n  \n\n  \n\n### Rewards \n\n  \n\nReward amounts are calculated based on the numerical CVSS score assigned to the report. \n\n  \n\nWe 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. \n\n  \n\n+ All bounty amounts will be at the discretion of the Starbucks Bug Bounty team. \n\n+ Reports submitted using methods that violate policy rules will not be eligible for reward. \n\n+ To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.   \n\n+ 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. \n\n+ 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. \n\n+ Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected. \n\n  \n\n  \n\n### Disclosure Requests  \n\n  \n\nAs of October 2024 Starbucks is no longer accepting disclosure requests. All vulnerabilities are strictly confidential. \n\n  \n\n  \n\n3. How do I make my report great? \n\n----------------- \n\nGreat reports lead to quicker resolution and more accurate reward. \n\n+ Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited. \n\n+ Utilize the CVSS v3 calculator to thoughtfully score your report.  \n\n+ Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding.  \n\n+ 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. \n\n+ Include your recommendations to resolve the issue. \n\n+ Be responsive to requests for additional information. \n\n+ Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved. \n\n+ Always be polite and respectful to HackerOne and Starbucks team members. \n\n  \n\nFor more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html \n\n  \n\n  \n\n  \n\n4. What causes a report to be closed as Informative, Duplicate, N/A or Spam? \n\n----------------- \n\nThese 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. \n\n  \n\n  \n\n### Spam \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Duplicate \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n### Informative \n\n+ Issues with minimal impact or relating to common security practices that are not prioritized for remediation.   \n\n+ Reports notifying us of broken links or abandoned Social Media accounts. \n\n+ Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls. \n\n+ 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. \n\n+ 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. \n\n  \n\n### N/A \n\n+ Violating program rules defined by HackerOne or those defined within this Starbucks program policy. \n\n+ Reports submitted for assets that clearly do not belong to Starbucks. \n\n+ Reports identifying issues described in our list of Exclusions. \n\n+ Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions. \n\n+ SDTO reports without a working proof of concept confirming you have control over the subdomain in question. \n\n+ 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. \n\n  \n\n_*Exclusions*_ \n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance.* \n\n+ Reports from automated tools or scans. \n\n+ Reports of credentials exposed by other data breaches / known credential lists. \n\n+ Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers.  \n\n+ Reports about insecure SSL/TLS configuration. \n\n+ Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing). \n\n+ Presence of publicly accessible login pages. \n\n+ Use of outdated software/library versions. \n\n+ Use of a known-vulnerable library without a description of an exploit specific to our implementation. \n\n+ OPTIONS/TRACE HTTP method enabled. \n\n+ Disclosure of known public files or directories. \n\n+ Presence of autocomplete functionality in form fields. \n\n+ Cookies that lack HTTP Only or Secure settings. \n\n+ Clickjacking and issues only exploitable through clickjacking. \n\n+ Attacks requiring physical access to a user's device or MITM attacks. \n\n+ Attacks dependent upon social engineering of Starbucks employees or vendors. \n\n+ Username enumeration based on login, forgot password, account creation and registration pages. \n\n+ Password or account recovery policies, such as reset link expiration or password complexity. \n\n+ Session management concerns such as session duration, concurrent active sessions or session invalidation triggers. \n\n+ Lack of email address verification during account registration. \n\n+ Enforcement policies for brute force or account lockout. \n\n+ Rate-limiting issues. \n\n+ Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these. \n\n+ Configuration of or missing security headers. \n\n+ Mixed content issues. \n\n+ CSRF on logout. \n\n+ CSRF on forms that are available to anonymous users. \n\n+ Self-XSS and issues exploitable only through Self-XSS. \n\n+ Content spoofing/text injection. \n\n+ Hyperlink injection in emails using forms available to any user.  \n\n+ Lack of obfuscation in mobile apps. \n\n+ Absence of certificate pinning. \n\n+ Lack of jailbreak detection in mobile apps. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nHelpful Hints \n\n______________________________________________________________________________________________________________________ \n\n  \n\n+ Read \u0026 follow the rules. \n\n+ 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.  \n\n+ 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/. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Appropriate Proof of Concepts \n\n+ SQLi\u0026nbsp;\u0026nbsp;- A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you. \n\n+ RCE\u0026nbsp;\u0026nbsp;- A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system. \n\n+ 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.  \n______________________________________________________________________________________________________________________ \n\nFAQ's \n______________________________________________________________________________________________________________________ \n\n1.\tCan I get Starbucks swag? \n\n+ Starbucks does not currently offer swag. \n\n2.\tCan Starbucks provide me with a pre-configured test account or Starbucks card(s)? \n\n+ Starbucks does not offer test accounts or test cards. \n\n3.\tAre all APIs / endpoints initiated by an in-scope mobile or web application eligible for bounty? \n\n+ No. Some APIs accessed by Starbucks applications are not developed or maintained by Starbucks application development teams. If reported through our program and we can act to mitigate a vulnerability, we may triage the report as a valid finding, but it would not be eligible for bounty. \n\n  \n\n### How to proceed in this situation: \n\nSet the asset type to the primary application you were testing. Ensure that your write up, includes the specifics for your proof of concept detailing: \n\n  \n\n+ How you tested this \n\n+ Which back end API call(s) had the vulnerability \n\n  \n\nStarbucks will review the report and determine whether it remains in-scope and bounty eligible under that primary asset. \n\n  \n\nA mobile application example can be found within our current scope: \n\nAndroid Play Store: com.starbucks.singapore \n\nAssets eligible for bounty referenced directly by this app: \n\nhttps://mobile.starbucks.com.sg \n\n\nA 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. \n\n\n\nThank you for helping keep Starbucks and our users safe! \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Google API Keys\",\"details\":\"Starbucks does not accept submissions for leaked Google API Keys\"}","{\"category\":\"ServiceNow Readable Knowledge Based Articles\",\"details\":\"Starbucks does not accept submissions for ServiceNow KBA's being readable to unauthenticated users.\"}"],"timestamp":"2024-11-06T22:04:39.106Z"},{"id":3743903,"new_policy":"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.  \n\n  \n###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. \n\nStarbucks 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. \n\n  \n\nProgram’s Geographic Regions: \n\n(Parent Program) – North America \nLatin America and Caribbean \nEurope, and Middle East and Africa \nChina \nJapan \n Asia Pacific and India \n\n \n\n \n\n  \n\n\u0026nbsp; \n\n______________________________________________________________________________________________________________________ \n\n  \n\nTable of Contents \n\n============ \n\n______________________________________________________________________________________________________________________ \n\n  \n\n  \n\n### Program \n\n1. Legal \n\n3. Program Eligibility \n\n4. Program Rules \n\n  \n\n### Report Submissions \n\n1. What is required when submitting a report? \n\n2. What happens after you submit a report? \n\n3. How do I make my report great? \n\n4. What causes a report to be closed as Informative, Duplicate, N/A, or Spam? \n\n  \n\n### Helpful Hints \n\n### FAQ's \n\n  \n\n\u0026nbsp; \n\n  \n\n______________________________________________________________________________________________________________________ \n\n  \n\nProgram \n\n============ \n\n________________________________________ \n\n  \n\n1. Legal \n\n----------------- \n\nStarbucks 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. \n\n  \n\n2. Program Eligibility \n\n----------------- \n\n+ You must agree and adhere to the Program Rules and Legal terms as stated in this policy. \n\n+ You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty. \n\n+ You must be available to supply additional information, as needed by our team, to reproduce and triage the issue. \n\n+ Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability. \n\n+ Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible. \n\n+ Starbucks partners (employees) and vendors are not eligible for participation in this program. \n\n  \n\n3. Program Rules \n\n----------------- \n\n### Do \n\n+ Read and abide by the program policy. \n\n+ 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. \n\n+ Exercise caution when testing to avoid negative impact to customers and the services they depend on. \n\n+ 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. \n\n  \n\n### Do NOT \n\n+ Do not Brute force credentials or guess credentials to gain access to systems. \n\n+ Do not participate in denial of service attacks. \n\n+ Do not upload shells or create a backdoor of any kind. \n\n+ Do not engage in any form of social engineering of Starbucks employees, customers, or vendors. \n\n+ Do not engage or target any Starbucks employee, customer or vendor during your testing. \n\n+ Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own.  \n\n+ 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.  \n\n+ Do not publicly disclose any vulnerabilities proposed to Starbucks. The Starbucks program is strictly confidential. \n\n+ 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. \n\n+ Any violation of these rules can lead to a prgram ban. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nReport Submissions \n\n______________________________________________________________________________________________________________________ \n\n  \n\n  \n\n1. What is required when submitting a report? \n\n----------------- \n\nProvide the information asked for by the new report form, following the instructions there. Some important considerations include: \n\n+ Title – this should be a quick and clear summary of your issue. \n\n+ Asset – this should match exactly the asset you are reporting, or “Other”. \n\n+ Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity. \n\n+ Weakness – select the most appropriate vulnerability type.  \n\n+ Description – provide all the requested fields. \n\n  \n\n  \n\n2. What happens after you submit a report? \n\n-----------------   \n\nStarbucks 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. \n\n \n\nStarbucks may close the report as \"Duplicate\", \"Informative\", \"N/A\", \"Spam\", or continue to work with you if more information is needed.  \n\n \n\nOnce 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. \n\n \n\nThe 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. \n\n \"Triage\" means the report is valid \u0026  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\". \n\n \n\n  \n\n  \n\n### Rewards \n\n  \n\nReward amounts are calculated based on the numerical CVSS score assigned to the report. \n\n  \n\nWe 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. \n\n  \n\n+ All bounty amounts will be at the discretion of the Starbucks Bug Bounty team. \n\n+ Reports submitted using methods that violate policy rules will not be eligible for reward. \n\n+ To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.   \n\n+ 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. \n\n+ 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. \n\n+ Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected. \n\n  \n\n  \n\n### Disclosure Requests  \n\n  \n\nAs of October 2024 Starbucks is no longer accepting disclosure requests. All vulnerabilities are strictly confidential. \n\n  \n\n  \n\n3. How do I make my report great? \n\n----------------- \n\nGreat reports lead to quicker resolution and more accurate reward. \n\n+ Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited. \n\n+ Utilize the CVSS v3 calculator to thoughtfully score your report.  \n\n+ Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding.  \n\n+ 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. \n\n+ Include your recommendations to resolve the issue. \n\n+ Be responsive to requests for additional information. \n\n+ Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved. \n\n+ Always be polite and respectful to HackerOne and Starbucks team members. \n\n  \n\nFor more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html \n\n  \n\n  \n\n  \n\n4. What causes a report to be closed as Informative, Duplicate, N/A or Spam? \n\n----------------- \n\nThese 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. \n\n  \n\n  \n\n### Spam \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Duplicate \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n### Informative \n\n+ Issues with minimal impact or relating to common security practices that are not prioritized for remediation.   \n\n+ Reports notifying us of broken links or abandoned Social Media accounts. \n\n+ Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls. \n\n+ 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. \n\n+ 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. \n\n  \n\n### N/A \n\n+ Violating program rules defined by HackerOne or those defined within this Starbucks program policy. \n\n+ Reports submitted for assets that clearly do not belong to Starbucks. \n\n+ Reports identifying issues described in our list of Exclusions. \n\n+ Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions. \n\n+ SDTO reports without a working proof of concept confirming you have control over the subdomain in question. \n\n+ 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. \n\n  \n\n_*Exclusions*_ \n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance.* \n\n+ Reports from automated tools or scans. \n\n+ Reports of credentials exposed by other data breaches / known credential lists. \n\n+ Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers.  \n\n+ Reports about insecure SSL/TLS configuration. \n\n+ Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing). \n\n+ Presence of publicly accessible login pages. \n\n+ Use of outdated software/library versions. \n\n+ Use of a known-vulnerable library without a description of an exploit specific to our implementation. \n\n+ OPTIONS/TRACE HTTP method enabled. \n\n+ Disclosure of known public files or directories. \n\n+ Presence of autocomplete functionality in form fields. \n\n+ Cookies that lack HTTP Only or Secure settings. \n\n+ Clickjacking and issues only exploitable through clickjacking. \n\n+ Attacks requiring physical access to a user's device or MITM attacks. \n\n+ Attacks dependent upon social engineering of Starbucks employees or vendors. \n\n+ Username enumeration based on login, forgot password, account creation and registration pages. \n\n+ Password or account recovery policies, such as reset link expiration or password complexity. \n\n+ Session management concerns such as session duration, concurrent active sessions or session invalidation triggers. \n\n+ Lack of email address verification during account registration. \n\n+ Enforcement policies for brute force or account lockout. \n\n+ Rate-limiting issues. \n\n+ Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these. \n\n+ Configuration of or missing security headers. \n\n+ Mixed content issues. \n\n+ CSRF on logout. \n\n+ CSRF on forms that are available to anonymous users. \n\n+ Self-XSS and issues exploitable only through Self-XSS. \n\n+ Content spoofing/text injection. \n\n+ Hyperlink injection in emails using forms available to any user.  \n\n+ Lack of obfuscation in mobile apps. \n\n+ Absence of certificate pinning. \n\n+ Lack of jailbreak detection in mobile apps. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nHelpful Hints \n\n______________________________________________________________________________________________________________________ \n\n  \n\n+ Read \u0026 follow the rules. \n\n+ 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.  \n\n+ 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/. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Appropriate Proof of Concepts \n\n+ SQLi\u0026nbsp;\u0026nbsp;- A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you. \n\n+ RCE\u0026nbsp;\u0026nbsp;- A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system. \n\n+ 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.  \n______________________________________________________________________________________________________________________ \n\nFAQ's \n______________________________________________________________________________________________________________________ \n\n1.\tCan I get Starbucks swag? \n\n+ Starbucks does not currently offer swag. \n\n2.\tCan Starbucks provide me with a pre-configured test account or Starbucks card(s)? \n\n+ Starbucks does not offer test accounts or test cards. \n\n3.\tAre all APIs / endpoints initiated by an in-scope mobile or web application eligible for bounty? \n\n+ No. Some APIs accessed by Starbucks applications are not developed or maintained by Starbucks application development teams. If reported through our program and we can act to mitigate a vulnerability, we may triage the report as a valid finding, but it would not be eligible for bounty. \n\n  \n\n### How to proceed in this situation: \n\nSet the asset type to the primary application you were testing. Ensure that your write up, includes the specifics for your proof of concept detailing: \n\n  \n\n+ How you tested this \n\n+ Which back end API call(s) had the vulnerability \n\n  \n\nStarbucks will review the report and determine whether it remains in-scope and bounty eligible under that primary asset. \n\n  \n\nA mobile application example can be found within our current scope: \n\nAndroid Play Store: com.starbucks.singapore \n\nAssets eligible for bounty referenced directly by this app: \n\nhttps://mobile.starbucks.com.sg \n\n\nA 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. \n\n\n\nThank you for helping keep Starbucks and our users safe! \n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Google API Keys\",\"details\":\"Starbucks does not accept submissions for leaked Google API Keys\"}","{\"category\":\"ServiceNow Readable Knowledge Based Articles\",\"details\":\"Starbucks does not accept submissions for ServiceNow KBA's being readable to unauthenticated users.\"}"],"timestamp":"2024-11-06T22:02:09.744Z"},{"id":3743869,"new_policy":"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.  \n\n  \n\n###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. \n\nStarbucks 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. \n\n  \n\nProgram’s Geographic Regions: \n\n(Parent Program) – North America \n\n Latin America and Caribbean \n\nEurope, and Middle East and Africa \n\n China \n\nJapan \n\n Asia Pacific and India \n\n \n\n \n\n  \n\n\u0026nbsp; \n\n______________________________________________________________________________________________________________________ \n\n  \n\nTable of Contents \n\n============ \n\n______________________________________________________________________________________________________________________ \n\n  \n\n  \n\n### Program \n\n1. Legal \n\n3. Program Eligibility \n\n4. Program Rules \n\n  \n\n### Report Submissions \n\n1. What is required when submitting a report? \n\n2. What happens after you submit a report? \n\n3. How do I make my report great? \n\n4. What causes a report to be closed as Informative, Duplicate, N/A, or Spam? \n\n  \n\n### Helpful Hints \n\n### FAQ's \n\n  \n\n\u0026nbsp; \n\n  \n\n______________________________________________________________________________________________________________________ \n\n  \n\nProgram \n\n============ \n\n________________________________________ \n\n  \n\n1. Legal \n\n----------------- \n\nStarbucks 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. \n\n  \n\n2. Program Eligibility \n\n----------------- \n\n+ You must agree and adhere to the Program Rules and Legal terms as stated in this policy. \n\n+ You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty. \n\n+ You must be available to supply additional information, as needed by our team, to reproduce and triage the issue. \n\n+ Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability. \n\n+ Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible. \n\n+ Starbucks partners (employees) and vendors are not eligible for participation in this program. \n\n  \n\n3. Program Rules \n\n----------------- \n\n### Do \n\n+ Read and abide by the program policy. \n\n+ 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. \n\n+ Exercise caution when testing to avoid negative impact to customers and the services they depend on. \n\n+ 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. \n\n  \n\n### Do NOT \n\n+ Do not Brute force credentials or guess credentials to gain access to systems. \n\n+ Do not participate in denial of service attacks. \n\n+ Do not upload shells or create a backdoor of any kind. \n\n+ Do not engage in any form of social engineering of Starbucks employees, customers, or vendors. \n\n+ Do not engage or target any Starbucks employee, customer or vendor during your testing. \n\n+ Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own.  \n\n+ 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.  \n\n+ Do not publicly disclose any vulnerabilities proposed to Starbucks. The Starbucks program is strictly confidential. \n\n+ 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. \n\n+ Any violation of these rules can lead to a prgram ban. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nReport Submissions \n\n============= \n\n______________________________________________________________________________________________________________________ \n\n  \n\n  \n\n1. What is required when submitting a report? \n\n----------------- \n\nProvide the information asked for by the new report form, following the instructions there. Some important considerations include: \n\n+ Title – this should be a quick and clear summary of your issue. \n\n+ Asset – this should match exactly the asset you are reporting, or “Other”. \n\n+ Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity. \n\n+ Weakness – select the most appropriate vulnerability type.  \n\n+ Description – provide all the requested fields. \n\n  \n\n  \n\n2. What happens after you submit a report? \n\n-----------------   \n\nStarbucks 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. \n\n \n\nStarbucks may close the report as \"Duplicate\", \"Informative\", \"N/A\", \"Spam\", or continue to work with you if more information is needed.  \n\n \n\nOnce 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. \n\n \n\nThe 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. \n\n \"Triage\" means the report is valid \u0026  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\". \n\n \n\n  \n\n  \n\n### Rewards \n\n  \n\nReward amounts are calculated based on the numerical CVSS score assigned to the report. \n\n  \n\nWe 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. \n\n  \n\n+ All bounty amounts will be at the discretion of the Starbucks Bug Bounty team. \n\n+ Reports submitted using methods that violate policy rules will not be eligible for reward. \n\n+ To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.   \n\n+ 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. \n\n+ 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. \n\n+ Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected. \n\n  \n\n  \n\n### Disclosure Requests  \n\n  \n\nAs of October 2024 Starbucks is no longer accepting disclosure requests. All vulnerabilities are strictly confidential. \n\n  \n\n  \n\n3. How do I make my report great? \n\n----------------- \n\nGreat reports lead to quicker resolution and more accurate reward. \n\n+ Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited. \n\n+ Utilize the CVSS v3 calculator to thoughtfully score your report.  \n\n+ Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding.  \n\n+ 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. \n\n+ Include your recommendations to resolve the issue. \n\n+ Be responsive to requests for additional information. \n\n+ Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved. \n\n+ Always be polite and respectful to HackerOne and Starbucks team members. \n\n  \n\nFor more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html \n\n  \n\n  \n\n  \n\n4. What causes a report to be closed as Informative, Duplicate, N/A or Spam? \n\n----------------- \n\nThese 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. \n\n  \n\n  \n\n### Spam \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Duplicate \n\n+ 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. \n\n+ 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. \n\n  \n\n  \n\n### Informative \n\n+ Issues with minimal impact or relating to common security practices that are not prioritized for remediation.   \n\n+ Reports notifying us of broken links or abandoned Social Media accounts. \n\n+ Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls. \n\n+ 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. \n\n+ 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. \n\n  \n\n### N/A \n\n+ Violating program rules defined by HackerOne or those defined within this Starbucks program policy. \n\n+ Reports submitted for assets that clearly do not belong to Starbucks. \n\n+ Reports identifying issues described in our list of Exclusions. \n\n+ Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions. \n\n+ SDTO reports without a working proof of concept confirming you have control over the subdomain in question. \n\n+ 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. \n\n  \n\n_*Exclusions*_ \n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance.* \n\n+ Reports from automated tools or scans. \n\n+ Reports of credentials exposed by other data breaches / known credential lists. \n\n+ Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers.  \n\n+ Reports about insecure SSL/TLS configuration. \n\n+ Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing). \n\n+ Presence of publicly accessible login pages. \n\n+ Use of outdated software/library versions. \n\n+ Use of a known-vulnerable library without a description of an exploit specific to our implementation. \n\n+ OPTIONS/TRACE HTTP method enabled. \n\n+ Disclosure of known public files or directories. \n\n+ Presence of autocomplete functionality in form fields. \n\n+ Cookies that lack HTTP Only or Secure settings. \n\n+ Clickjacking and issues only exploitable through clickjacking. \n\n+ Attacks requiring physical access to a user's device or MITM attacks. \n\n+ Attacks dependent upon social engineering of Starbucks employees or vendors. \n\n+ Username enumeration based on login, forgot password, account creation and registration pages. \n\n+ Password or account recovery policies, such as reset link expiration or password complexity. \n\n+ Session management concerns such as session duration, concurrent active sessions or session invalidation triggers. \n\n+ Lack of email address verification during account registration. \n\n+ Enforcement policies for brute force or account lockout. \n\n+ Rate-limiting issues. \n\n+ Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these. \n\n+ Configuration of or missing security headers. \n\n+ Mixed content issues. \n\n+ CSRF on logout. \n\n+ CSRF on forms that are available to anonymous users. \n\n+ Self-XSS and issues exploitable only through Self-XSS. \n\n+ Content spoofing/text injection. \n\n+ Hyperlink injection in emails using forms available to any user.  \n\n+ Lack of obfuscation in mobile apps. \n\n+ Absence of certificate pinning. \n\n+ Lack of jailbreak detection in mobile apps. \n\n  \n\n______________________________________________________________________________________________________________________ \n\nHelpful Hints \n\n=============== \n\n______________________________________________________________________________________________________________________ \n\n  \n\n+ Read \u0026 follow the rules. \n\n+ 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.  \n\n+ 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/. \n\n+ 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. \n\n  \n\n  \n\n  \n\n### Appropriate Proof of Concepts \n\n+ SQLi\u0026nbsp;\u0026nbsp;- A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you. \n\n+ RCE\u0026nbsp;\u0026nbsp;- A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system. \n\n+ 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.  \n\n  \n\n  \n\n______________________________________________________________________________________________________________________ \n\nFAQ's \n\n============ \n\n______________________________________________________________________________________________________________________ \n\n1.\tCan I get Starbucks swag? \n\n+ Starbucks does not currently offer swag. \n\n2.\tCan Starbucks provide me with a pre-configured test account or Starbucks card(s)? \n\n+ Starbucks does not offer test accounts or test cards. \n\n3.\tAre all APIs / endpoints initiated by an in-scope mobile or web application eligible for bounty? \n\n+ No. Some APIs accessed by Starbucks applications are not developed or maintained by Starbucks application development teams. If reported through our program and we can act to mitigate a vulnerability, we may triage the report as a valid finding, but it would not be eligible for bounty. \n\n  \n\n### How to proceed in this situation: \n\nSet the asset type to the primary application you were testing. Ensure that your write up, includes the specifics for your proof of concept detailing: \n\n  \n\n+ How you tested this \n\n+ Which back end API call(s) had the vulnerability \n\n  \n\nStarbucks will review the report and determine whether it remains in-scope and bounty eligible under that primary asset. \n\n  \n\nA mobile application example can be found within our current scope: \n\nAndroid Play Store: com.starbucks.singapore \n\nAssets eligible for bounty referenced directly by this app: \n\nhttps://mobile.starbucks.com.sg \n\n  \n\nA 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. \n\n  \n\n  \n\nThank you for helping keep Starbucks and our users safe! \n\n====================================== \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Google API Keys\",\"details\":\"Starbucks does not accept submissions for leaked Google API Keys\"}","{\"category\":\"ServiceNow Readable Knowledge Based Articles\",\"details\":\"Starbucks does not accept submissions for ServiceNow KBA's being readable to unauthenticated users.\"}"],"timestamp":"2024-11-06T18:55:27.130Z"},{"id":3742915,"new_policy":"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. \n\n###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.\n\n\u0026nbsp;\n______________________________________________________________________________________________________________________\n\nTable of Contents\n============\n______________________________________________________________________________________________________________________\n\n\n### Program\n 1. Legal\n 3. Program Eligibility\n 4. Program Rules\n\n### Report Submissions\n1. What is required when submitting a report?\n2. What happens after you submit a report?\n3. How do I make my report great?\n4. What causes a report to be closed as Informative, Duplicate, N/A, or Spam?\n\n### Helpful Hints\n### FAQ's\n\n\u0026nbsp;\n\n______________________________________________________________________________________________________________________\n\nProgram\n============\n________________________________________\n \n1. Legal\n-----------------\nStarbucks 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.\n \n 2. Program Eligibility\n-----------------\n+ You must agree and adhere to the Program Rules and Legal terms as stated in this policy.\n+ You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty.\n+ You must be available to supply additional information, as needed by our team, to reproduce and triage the issue.\n+ Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability.\n+ Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible.\n+ Starbucks partners (employees) and vendors are not eligible for participation in this program.\n\n 3. Program Rules\n-----------------\n### Do\n+ Read and abide by the program policy.\n+ 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.\n+ Exercise caution when testing to avoid negative impact to customers and the services they depend on.\n+ 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.\n\n### Do NOT\n+ Do not Brute force credentials or guess credentials to gain access to systems.\n+ Do not participate in denial of service attacks.\n+ Do not upload shells or create a backdoor of any kind.\n+ Do not engage in any form of social engineering of Starbucks employees, customers, or vendors.\n+ Do not engage or target any Starbucks employee, customer or vendor during your testing.\n+ Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own. \n+ 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. \n+ Do not publicly disclose vulnerability reports that are not resolved and approved for disclosure by Starbucks.\n+ 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.\n\n______________________________________________________________________________________________________________________\nReport Submissions\n=============\n______________________________________________________________________________________________________________________\n\n \n 1. What is required when submitting a report?\n-----------------\nProvide the information asked for by the new report form, following the instructions there. Some important considerations include:\n+ Title – this should be a quick and clear summary of your issue.\n+ Asset – this should match exactly the asset you are reporting, or “Other”.\n+ Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity.\n+ Weakness – select the most appropriate vulnerability type. \n+ Description – provide all the requested fields.\n\n\n 2. What happens after you submit a report?\n-----------------  \nHackerOne triage 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.\n\nHackerOne triage may close the report as \"Duplicate\", \"Informative\", \"N/A\", \"Spam\", or continue to work with you if more information is needed. They will not move the report to \"Triaged\".\nOnce validated by HackerOne, the triager will assign the report to Starbucks, letting you know in the report with a short message to that effect. \n\nThe Starbucks team will then review your report. We will be working on the issue but may not have enough information to immediately move it from \"New\" to \"Triage\".  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.   \n\nStarbucks will \"Triage\" valid \u0026 eligible reports that 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\".\n \n \n### Rewards\n\nReward amounts are calculated based on the numerical CVSS score assigned to the report.\n\nWe 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.\n\n+ All bounty amounts will be at the discretion of the Starbucks Bug Bounty team.\n+ Reports that include a unique [Nuclei Template](https://github.com/projectdiscovery/nuclei) to validate the finding will be rewarded a $250 bonus. \n    + Starbucks will not bonus submissions that include an open-source community template demonstrating vulnerability findings. The template must be unique for the vulnerability being demonstrated.\n    + Starbucks retains a perpetual right to utilize any templates submitted as part of a report and will not make any templates provided to Starbucks available to the public.\n+ Reports submitted using methods that violate policy rules will not be eligible for reward.\n+ To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.  \n+ 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.\n+ 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.\n+ Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected.\n\n \n### Disclosure Requests \n\nTo request disclosure, follow the guidelines as outlined by HackerOne: https://docs.hackerone.com/programs/disclosure.html.\n\nOnce Starbucks receives your official disclosure request, we may take the following actions:\n* Redact any sensitive information.\n* Include a Starbucks provided summary.\n* Make adjustments to report metadata to ensure clarity and accuracy, if needed.\n\nOnly reports for in-scope assets that have been closed as 'Resolved' will be considered for disclosure. \nDisclosure requests must be received within 90 days of the report being closed as 'Resolved'.\n\n \n3. How do I make my report great?\n-----------------\nGreat reports lead to quicker resolution and more accurate reward.\n+ Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited.\n+ Utilize the CVSS v3 calculator to thoughtfully score your report. \n+ Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding. \n+ 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.\n+ Include your recommendations to resolve the issue.\n+ Be responsive to requests for additional information.\n+ Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved.\n+ Always be polite and respectful to HackerOne and Starbucks team members.\n\nFor more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html\n \n \n \n4. What causes a report to be closed as Informative, Duplicate, N/A or Spam?\n-----------------\nThese 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.\n\n \n### Spam\n+ 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.\n+ 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.\n\n\n \n### Duplicate\n+ 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.\n+ 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.\n\n \n### Informative\n+ Issues with minimal impact or relating to common security practices that are not prioritized for remediation.  \n+ Reports notifying us of broken links or abandoned Social Media accounts.\n+ Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls.\n+ 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.\n+ 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.\n \n### N/A\n+ Violating program rules defined by HackerOne or those defined within this Starbucks program policy.\n+ Reports submitted for assets that clearly do not belong to Starbucks.\n+ Reports identifying issues described in our list of Exclusions.\n+ Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions.\n+ SDTO reports without a working proof of concept confirming you have control over the subdomain in question.\n+ 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.\n\n_*Exclusions*_\n *Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance.*\n+ Reports from automated tools or scans.\n+ Reports of credentials exposed by other data breaches / known credential lists.\n+ Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers. \n+ Reports about insecure SSL/TLS configuration.\n+ Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing).\n+ Presence of publicly accessible login pages.\n+ Use of outdated software/library versions.\n+ Use of a known-vulnerable library without a description of an exploit specific to our implementation.\n+ OPTIONS/TRACE HTTP method enabled.\n+ Disclosure of known public files or directories.\n+ Presence of autocomplete functionality in form fields.\n+ Cookies that lack HTTP Only or Secure settings.\n+ Clickjacking and issues only exploitable through clickjacking.\n+ Attacks requiring physical access to a user's device or MITM attacks.\n+ Attacks dependent upon social engineering of Starbucks employees or vendors.\n+ Username enumeration based on login, forgot password, account creation and registration pages.\n+ Password or account recovery policies, such as reset link expiration or password complexity.\n+ Session management concerns such as session duration, concurrent active sessions or session invalidation triggers.\n+ Lack of email address verification during account registration.\n+ Enforcement policies for brute force or account lockout.\n+ Rate-limiting issues.\n+ Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these.\n+ Configuration of or missing security headers.\n+ Mixed content issues.\n+ CSRF on logout.\n+ CSRF on forms that are available to anonymous users.\n+ Self-XSS and issues exploitable only through Self-XSS.\n+ Content spoofing/text injection.\n+ Hyperlink injection in emails using forms available to any user. \n+ Lack of obfuscation in mobile apps.\n+ Absence of certificate pinning.\n+ Lack of jailbreak detection in mobile apps.\n\n______________________________________________________________________________________________________________________\nHelpful Hints\n===============\n______________________________________________________________________________________________________________________\n\n+ Read \u0026 follow the rules.\n+ 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. \n+ 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/.\n+ 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.\n \n\n\n### Appropriate Proof of Concepts\n+ SQLi\u0026nbsp;\u0026nbsp;- A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you.\n+ RCE\u0026nbsp;\u0026nbsp;- A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system.\n+ 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. \n\n\n______________________________________________________________________________________________________________________\nFAQ's\n============\n______________________________________________________________________________________________________________________\n1.\tCan I get Starbucks swag?\n + Starbucks does not currently offer swag.\n2.\tCan Starbucks provide me with a pre-configured test account or Starbucks card(s)?\n + Starbucks does not offer test accounts or test cards.\n3.\tAre all APIs / endpoints initiated by an in-scope mobile or web application eligible for bounty?\n + No. Some APIs accessed by Starbucks applications are not developed or maintained by Starbucks application development teams. If reported through our program and we can act to mitigate a vulnerability, we may triage the report as a valid finding, but it would not be eligible for bounty.\n\n### How to proceed in this situation:\nSet the asset type to the primary application you were testing. Ensure that your write up, includes the specifics for your proof of concept detailing:\n\n + How you tested this\n + Which back end API call(s) had the vulnerability\n\nStarbucks will review the report and determine whether it remains in-scope and bounty eligible under that primary asset.\n\nA mobile application example can be found within our current scope:\nAndroid Play Store: com.starbucks.singapore\nAssets eligible for bounty referenced directly by this app:\nhttps://mobile.starbucks.com.sg\n\nA 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.\n\n\nThank you for helping keep Starbucks and our users safe!\n======================================\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Google API Keys\",\"details\":\"Starbucks does not accept submissions for leaked Google API Keys\"}","{\"category\":\"ServiceNow Readable Knowledge Based Articles\",\"details\":\"Starbucks does not accept submissions for ServiceNow KBA's being readable to unauthenticated users.\"}"],"timestamp":"2024-10-24T17:34:30.687Z"},{"id":3676121,"new_policy":"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. \n\n###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.\n\n\u0026nbsp;\n______________________________________________________________________________________________________________________\n\nTable of Contents\n============\n______________________________________________________________________________________________________________________\n\n\n### Program\n 1. Legal\n 3. Program Eligibility\n 4. Program Rules\n\n### Report Submissions\n1. What is required when submitting a report?\n2. What happens after you submit a report?\n3. How do I make my report great?\n4. What causes a report to be closed as Informative, Duplicate, N/A, or Spam?\n\n### Helpful Hints\n### FAQ's\n\n\u0026nbsp;\n\n______________________________________________________________________________________________________________________\n\nProgram\n============\n________________________________________\n \n1. Legal\n-----------------\nStarbucks 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.\n \n 2. Program Eligibility\n-----------------\n+ You must agree and adhere to the Program Rules and Legal terms as stated in this policy.\n+ You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty.\n+ You must be available to supply additional information, as needed by our team, to reproduce and triage the issue.\n+ Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability.\n+ Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible.\n+ Starbucks partners (employees) and vendors are not eligible for participation in this program.\n\n 3. Program Rules\n-----------------\n### Do\n+ Read and abide by the program policy.\n+ 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.\n+ Exercise caution when testing to avoid negative impact to customers and the services they depend on.\n+ 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.\n\n### Do NOT\n+ Do not Brute force credentials or guess credentials to gain access to systems.\n+ Do not participate in denial of service attacks.\n+ Do not upload shells or create a backdoor of any kind.\n+ Do not engage in any form of social engineering of Starbucks employees, customers, or vendors.\n+ Do not engage or target any Starbucks employee, customer or vendor during your testing.\n+ Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own. \n+ 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. \n+ Do not publicly disclose vulnerability reports that are not resolved and approved for disclosure by Starbucks.\n+ 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.\n\n______________________________________________________________________________________________________________________\nReport Submissions\n=============\n______________________________________________________________________________________________________________________\n\n \n 1. What is required when submitting a report?\n-----------------\nProvide the information asked for by the new report form, following the instructions there. Some important considerations include:\n+ Title – this should be a quick and clear summary of your issue.\n+ Asset – this should match exactly the asset you are reporting, or “Other”.\n+ Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity.\n+ Weakness – select the most appropriate vulnerability type. \n+ Description – provide all the requested fields.\n\n\n 2. What happens after you submit a report?\n-----------------  \nHackerOne triage 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.\n\nHackerOne triage may close the report as \"Duplicate\", \"Informative\", \"N/A\", \"Spam\", or continue to work with you if more information is needed. They will not move the report to \"Triaged\".\nOnce validated by HackerOne, the triager will assign the report to Starbucks, letting you know in the report with a short message to that effect. \n\nThe Starbucks team will then review your report. We will be working on the issue but may not have enough information to immediately move it from \"New\" to \"Triage\".  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.   \n\nStarbucks will \"Triage\" valid \u0026 eligible reports that 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\".\n \n \n### Rewards\n\nReward amounts are calculated based on the numerical CVSS score assigned to the report.\n\nWe 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.\n\n+ All bounty amounts will be at the discretion of the Starbucks Bug Bounty team.\n+ Reports that include a unique [Nuclei Template](https://github.com/projectdiscovery/nuclei) to validate the finding will be rewarded a $250 bonus. \n    + Starbucks will not bonus submissions that include an open-source community template demonstrating vulnerability findings. The template must be unique for the vulnerability being demonstrated.\n    + Starbucks retains a perpetual right to utilize any templates submitted as part of a report and will not make any templates provided to Starbucks available to the public.\n+ Reports submitted using methods that violate policy rules will not be eligible for reward.\n+ To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.  \n+ 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.\n+ 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.\n+ Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected.\n\n \n### Disclosure Requests \n\nTo request disclosure, follow the guidelines as outlined by HackerOne: https://docs.hackerone.com/programs/disclosure.html.\n\nOnce Starbucks receives your official disclosure request, we may take the following actions:\n* Redact any sensitive information.\n* Include a Starbucks provided summary.\n* Make adjustments to report metadata to ensure clarity and accuracy, if needed.\n\nOnly reports for in-scope assets that have been closed as 'Resolved' will be considered for disclosure. \nDisclosure requests must be received within 90 days of the report being closed as 'Resolved'.\n\n \n3. How do I make my report great?\n-----------------\nGreat reports lead to quicker resolution and more accurate reward.\n+ Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited.\n+ Utilize the CVSS v3 calculator to thoughtfully score your report. \n+ Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding. \n+ 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.\n+ Include your recommendations to resolve the issue.\n+ Be responsive to requests for additional information.\n+ Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved.\n+ Always be polite and respectful to HackerOne and Starbucks team members.\n\nFor more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html\n \n \n \n4. What causes a report to be closed as Informative, Duplicate, N/A or Spam?\n-----------------\nThese 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.\n\n \n### Spam\n+ 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.\n+ 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.\n\n\n \n### Duplicate\n+ 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.\n+ 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.\n\n \n### Informative\n+ Issues with minimal impact or relating to common security practices that are not prioritized for remediation.  \n+ Reports notifying us of broken links or abandoned Social Media accounts.\n+ Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls.\n+ 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.\n+ 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.\n \n### N/A\n+ Violating program rules defined by HackerOne or those defined within this Starbucks program policy.\n+ Reports submitted for assets that clearly do not belong to Starbucks.\n+ Reports identifying issues described in our list of Exclusions.\n+ Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions.\n+ SDTO reports without a working proof of concept confirming you have control over the subdomain in question.\n+ 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.\n\n_*Exclusions*_\n *Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance.*\n+ Reports from automated tools or scans.\n+ Reports of credentials exposed by other data breaches / known credential lists.\n+ Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers. \n+ Reports about insecure SSL/TLS configuration.\n+ Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing).\n+ Presence of publicly accessible login pages.\n+ Use of outdated software/library versions.\n+ Use of a known-vulnerable library without a description of an exploit specific to our implementation.\n+ OPTIONS/TRACE HTTP method enabled.\n+ Disclosure of known public files or directories.\n+ Presence of autocomplete functionality in form fields.\n+ Cookies that lack HTTP Only or Secure settings.\n+ Clickjacking and issues only exploitable through clickjacking.\n+ Attacks requiring physical access to a user's device or MITM attacks.\n+ Attacks dependent upon social engineering of Starbucks employees or vendors.\n+ Username enumeration based on login, forgot password, account creation and registration pages.\n+ Password or account recovery policies, such as reset link expiration or password complexity.\n+ Session management concerns such as session duration, concurrent active sessions or session invalidation triggers.\n+ Lack of email address verification during account registration.\n+ Enforcement policies for brute force or account lockout.\n+ Rate-limiting issues.\n+ Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these.\n+ Configuration of or missing security headers.\n+ Mixed content issues.\n+ CSRF on logout.\n+ CSRF on forms that are available to anonymous users.\n+ Self-XSS and issues exploitable only through Self-XSS.\n+ Content spoofing/text injection.\n+ Hyperlink injection in emails using forms available to any user. \n+ Lack of obfuscation in mobile apps.\n+ Absence of certificate pinning.\n+ Lack of jailbreak detection in mobile apps.\n\n______________________________________________________________________________________________________________________\nHelpful Hints\n===============\n______________________________________________________________________________________________________________________\n\n+ Read \u0026 follow the rules.\n+ 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. \n+ 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/.\n+ 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.\n \n\n\n### Appropriate Proof of Concepts\n+ SQLi\u0026nbsp;\u0026nbsp;- A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you.\n+ RCE\u0026nbsp;\u0026nbsp;- A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system.\n+ 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. \n\n\n______________________________________________________________________________________________________________________\nFAQ's\n============\n______________________________________________________________________________________________________________________\n1.\tCan I get Starbucks swag?\n + Starbucks does not currently offer swag.\n2.\tCan Starbucks provide me with a pre-configured test account or Starbucks card(s)?\n + Starbucks does not offer test accounts or test cards.\n3.\tAre all APIs / endpoints initiated by an in-scope mobile or web application eligible for bounty?\n + No. Some APIs accessed by Starbucks applications are not developed or maintained by Starbucks application development teams. If reported through our program and we can act to mitigate a vulnerability, we may triage the report as a valid finding, but it would not be eligible for bounty.\n\n### How to proceed in this situation:\nSet the asset type to the primary application you were testing. Ensure that your write up, includes the specifics for your proof of concept detailing:\n\n + How you tested this\n + Which back end API call(s) had the vulnerability\n\nStarbucks will review the report and determine whether it remains in-scope and bounty eligible under that primary asset.\n\nA mobile application example can be found within our current scope:\nAndroid Play Store: com.starbucks.singapore\nAssets eligible for bounty referenced directly by this app:\nhttps://mobile.starbucks.com.sg\n\nA 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.\n\n\nThank you for helping keep Starbucks and our users safe!\n======================================\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-08-15T20:31:50.973Z"},{"id":3645062,"new_policy":"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. \n\n###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.\n\n\u0026nbsp;\n______________________________________________________________________________________________________________________\n\nTable of Contents\n============\n______________________________________________________________________________________________________________________\n\n\n### Program\n 1. Legal\n 3. Program Eligibility\n 4. Program Rules\n\n### Report Submissions\n1. What is required when submitting a report?\n2. What happens after you submit a report?\n3. How do I make my report great?\n4. What causes a report to be closed as Informative, Duplicate, N/A, or Spam?\n\n### Helpful Hints\n### FAQ's\n\n\u0026nbsp;\n\n______________________________________________________________________________________________________________________\n\nProgram\n============\n________________________________________\n \n1. Legal\n-----------------\nStarbucks 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.\n \n 2. Program Eligibility\n-----------------\n+ You must agree and adhere to the Program Rules and Legal terms as stated in this policy.\n+ You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty.\n+ You must be available to supply additional information, as needed by our team, to reproduce and triage the issue.\n+ Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability.\n+ Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible.\n+ Starbucks partners (employees) and vendors are not eligible for participation in this program.\n\n 3. Program Rules\n-----------------\n### Do\n+ Read and abide by the program policy.\n+ 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.\n+ Exercise caution when testing to avoid negative impact to customers and the services they depend on.\n+ 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.\n\n### Do NOT\n+ Do not Brute force credentials or guess credentials to gain access to systems.\n+ Do not participate in denial of service attacks.\n+ Do not upload shells or create a backdoor of any kind.\n+ Do not engage in any form of social engineering of Starbucks employees, customers, or vendors.\n+ Do not engage or target any Starbucks employee, customer or vendor during your testing.\n+ Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own. \n+ 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. \n+ Do not publicly disclose vulnerability reports that are not resolved and approved for disclosure by Starbucks.\n+ 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.\n\n______________________________________________________________________________________________________________________\nReport Submissions\n=============\n______________________________________________________________________________________________________________________\n\n \n 1. What is required when submitting a report?\n-----------------\nProvide the information asked for by the new report form, following the instructions there. Some important considerations include:\n+ Title – this should be a quick and clear summary of your issue.\n+ Asset – this should match exactly the asset you are reporting, or “Other”.\n+ Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity.\n+ Weakness – select the most appropriate vulnerability type. \n+ Description – provide all the requested fields.\n\n\n 2. What happens after you submit a report?\n-----------------  \nHackerOne triage 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.\n\nHackerOne triage may close the report as \"Duplicate\", \"Informative\", \"N/A\", \"Spam\", or continue to work with you if more information is needed. They will not move the report to \"Triaged\".\nOnce validated by HackerOne, the triager will assign the report to Starbucks, letting you know in the report with a short message to that effect. \n\nThe Starbucks team will then review your report. We will be working on the issue but may not have enough information to immediately move it from \"New\" to \"Triage\".  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.   \n\nStarbucks will \"Triage\" valid \u0026 eligible reports that 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\".\n \n \n### Rewards\n\nReward amounts are calculated based on the numerical CVSS score assigned to the report.\n\nWe 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.\n\n+ All bounty amounts will be at the discretion of the Starbucks Bug Bounty team.\n+ Reports submitted using methods that violate policy rules will not be eligible for reward.\n+ To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.  \n+ 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.\n+ 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.\n+ Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected.\n\n \n### Disclosure Requests \n\nTo request disclosure, follow the guidelines as outlined by HackerOne: https://docs.hackerone.com/programs/disclosure.html.\n\nOnce Starbucks receives your official disclosure request, we may take the following actions:\n* Redact any sensitive information.\n* Include a Starbucks provided summary.\n* Make adjustments to report metadata to ensure clarity and accuracy, if needed.\n\nOnly reports for in-scope assets that have been closed as 'Resolved' will be considered for disclosure. \nDisclosure requests must be received within 90 days of the report being closed as 'Resolved'.\n\n \n3. How do I make my report great?\n-----------------\nGreat reports lead to quicker resolution and more accurate reward.\n\n+ Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited.\n+ Utilize the CVSS v3 calculator to thoughtfully score your report. \n+ Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding. \n+ 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.\n+ Include your recommendations to resolve the issue.\n+ Be responsive to requests for additional information.\n+ Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved.\n+ Always be polite and respectful to HackerOne and Starbucks team members.\n\nFor more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html\n \n \n \n4. What causes a report to be closed as Informative, Duplicate, N/A or Spam?\n-----------------\nThese 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.\n\n \n### Spam\n+ 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.\n+ 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.\n\n\n \n### Duplicate\n+ 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.\n+ 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.\n\n \n### Informative\n+ Issues with minimal impact or relating to common security practices that are not prioritized for remediation.  \n+ Reports notifying us of broken links or abandoned Social Media accounts.\n+ Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls.\n+ 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.\n+ 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.\n \n### N/A\n+ Violating program rules defined by HackerOne or those defined within this Starbucks program policy.\n+ Reports submitted for assets that clearly do not belong to Starbucks.\n+ Reports identifying issues described in our list of Exclusions.\n+ Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions.\n+ SDTO reports without a working proof of concept confirming you have control over the subdomain in question.\n+ 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.\n\n_*Exclusions*_\n *Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance.*\n+ Reports from automated tools or scans.\n+ Reports of credentials exposed by other data breaches / known credential lists.\n+ Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers. \n+ Reports about insecure SSL/TLS configuration.\n+ Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing).\n+ Presence of publicly accessible login pages.\n+ Use of outdated software/library versions.\n+ Use of a known-vulnerable library without a description of an exploit specific to our implementation.\n+ OPTIONS/TRACE HTTP method enabled.\n+ Disclosure of known public files or directories.\n+ Presence of autocomplete functionality in form fields.\n+ Cookies that lack HTTP Only or Secure settings.\n+ Clickjacking and issues only exploitable through clickjacking.\n+ Attacks requiring physical access to a user's device or MITM attacks.\n+ Attacks dependent upon social engineering of Starbucks employees or vendors.\n+ Username enumeration based on login, forgot password, account creation and registration pages.\n+ Password or account recovery policies, such as reset link expiration or password complexity.\n+ Session management concerns such as session duration, concurrent active sessions or session invalidation triggers.\n+ Lack of email address verification during account registration.\n+ Enforcement policies for brute force or account lockout.\n+ Rate-limiting issues.\n+ Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these.\n+ Configuration of or missing security headers.\n+ Mixed content issues.\n+ CSRF on logout.\n+ CSRF on forms that are available to anonymous users.\n+ Self-XSS and issues exploitable only through Self-XSS.\n+ Content spoofing/text injection.\n+ Hyperlink injection in emails using forms available to any user. \n+ Lack of obfuscation in mobile apps.\n+ Absence of certificate pinning.\n+ Lack of jailbreak detection in mobile apps.\n\n______________________________________________________________________________________________________________________\nHelpful Hints\n===============\n______________________________________________________________________________________________________________________\n\n+ Read \u0026 follow the rules.\n+ 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. \n+ 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/.\n+ 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.\n \n\n\n### Appropriate Proof of Concepts\n+ SQLi\u0026nbsp;\u0026nbsp;- A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you.\n+ RCE\u0026nbsp;\u0026nbsp;- A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system.\n+ 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. \n\n\n______________________________________________________________________________________________________________________\nFAQ's\n============\n______________________________________________________________________________________________________________________\n1.\tCan I get Starbucks swag?\n + Starbucks does not currently offer swag.\n2.\tCan Starbucks provide me with a pre-configured test account or Starbucks card(s)?\n + Starbucks does not offer test accounts or test cards.\n3.\tAre all APIs / endpoints initiated by an in-scope mobile or web application eligible for bounty?\n + No. Some APIs accessed by Starbucks applications are not developed or maintained by Starbucks application development teams. If reported through our program and we can act to mitigate a vulnerability, we may triage the report as a valid finding, but it would not be eligible for bounty.\n\n### How to proceed in this situation:\nSet the asset type to the primary application you were testing. Ensure that your write up, includes the specifics for your proof of concept detailing:\n\n + How you tested this\n + Which back end API call(s) had the vulnerability\n\nStarbucks will review the report and determine whether it remains in-scope and bounty eligible under that primary asset.\n\nA mobile application example can be found within our current scope:\nAndroid Play Store: com.starbucks.singapore\nAssets eligible for bounty referenced directly by this app:\nhttps://mobile.starbucks.com.sg\n\nA 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.\n\n\nThank you for helping keep Starbucks and our users safe!\n======================================\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-11-14T09:22:46.293Z"},{"id":3645061,"new_policy":"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. \n\n###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.\n\n\u0026nbsp;\n______________________________________________________________________________________________________________________\n\nTable of Contents\n============\n______________________________________________________________________________________________________________________\n\n\n### Program\n 1. Legal\n 3. Program Eligibility\n 4. Program Rules\n\n### Report Submissions\n1. What is required when submitting a report?\n2. What happens after you submit a report?\n3. How do I make my report great?\n4. What causes a report to be closed as Informative, Duplicate, N/A, or Spam?\n\n### Helpful Hints\n### FAQ's\n\n\u0026nbsp;\n\n______________________________________________________________________________________________________________________\n\nProgram\n============\n________________________________________\n \n1. Legal\n-----------------\nStarbucks 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.\n \n 2. Program Eligibility\n-----------------\n+ You must agree and adhere to the Program Rules and Legal terms as stated in this policy.\n+ You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty.\n+ You must be available to supply additional information, as needed by our team, to reproduce and triage the issue.\n+ Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability.\n+ Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible.\n+ Starbucks partners (employees) and vendors are not eligible for participation in this program.\n\n 3. Program Rules\n-----------------\n### Do\n+ Read and abide by the program policy.\n+ 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.\n+ Exercise caution when testing to avoid negative impact to customers and the services they depend on.\n+ 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.\n\n### Do NOT\n+ Do not Brute force credentials or guess credentials to gain access to systems.\n+ Do not participate in denial of service attacks.\n+ Do not upload shells or create a backdoor of any kind.\n+ Do not engage in any form of social engineering of Starbucks employees, customers, or vendors.\n+ Do not engage or target any Starbucks employee, customer or vendor during your testing.\n+ Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own. \n+ 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. \n+ Do not publicly disclose vulnerability reports that are not resolved and approved for disclosure by Starbucks.\n+ 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.\n\n______________________________________________________________________________________________________________________\nReport Submissions\n=============\n______________________________________________________________________________________________________________________\n\n \n 1. What is required when submitting a report?\n-----------------\nProvide the information asked for by the new report form, following the instructions there. Some important considerations include:\n+ Title – this should be a quick and clear summary of your issue.\n+ Asset – this should match exactly the asset you are reporting, or “Other”.\n+ Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity.\n+ Weakness – select the most appropriate vulnerability type. \n+ Description – provide all the requested fields.\n\n\n 2. What happens after you submit a report?\n-----------------  \nHackerOne triage 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.\n\nHackerOne triage may close the report as \"Duplicate\", \"Informative\", \"N/A\", \"Spam\", or continue to work with you if more information is needed. They will not move the report to \"Triaged\".\nOnce validated by HackerOne, the triager will assign the report to Starbucks, letting you know in the report with a short message to that effect. \n\nThe Starbucks team will then review your report. We will be working on the issue but may not have enough information to immediately move it from \"New\" to \"Triage\".  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.   \n\nStarbucks will \"Triage\" valid \u0026 eligible reports that 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\".\n \n \n### Rewards\n\nReward amounts are calculated based on the numerical CVSS score assigned to the report.\n\nWe 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.\n\n+ All bounty amounts will be at the discretion of the Starbucks Bug Bounty team.\n+ Reports submitted using methods that violate policy rules will not be eligible for reward.\n+ To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.  \n+ 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.\n+ 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.\n+ Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected.\n\n \n### Disclosure Requests \n\nTo request disclosure, follow the guidelines as outlined by HackerOne: https://docs.hackerone.com/programs/disclosure.html.\n\nOnce Starbucks receives your official disclosure request, we may take the following actions:\n* Redact any sensitive information.\n* Include a Starbucks provided summary.\n* Make adjustments to report metadata to ensure clarity and accuracy, if needed.\n\nOnly reports for in-scope assets that have been closed as 'Resolved' will be considered for disclosure. \nDisclosure requests must be received within 90 days of the report being closed as 'Resolved'.\n\n \n3. How do I make my report great?\n-----------------\nGreat reports lead to quicker resolution and more accurate reward.\n\n+ Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited.\n+ Utilize the CVSS v3 calculator to thoughtfully score your report. \n+ Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding. \n+ 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.\n+ Include your recommendations to resolve the issue.\n+ Be responsive to requests for additional information.\n+ Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved.\n+ Always be polite and respectful to HackerOne and Starbucks team members.\n\nFor more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html\n \n \n \n4. What causes a report to be closed as Informative, Duplicate, N/A or Spam?\n-----------------\nThese 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.\n\n \n### Spam\n+ 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.\n+ 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.\n\n\n \n### Duplicate\n+ 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.\n+ 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.\n\n \n### Informative\n+ Issues with minimal impact or relating to common security practices that are not prioritized for remediation.  \n+ Reports notifying us of broken links or abandoned Social Media accounts.\n+ Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls.\n+ 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.\n+ 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.\n \n### N/A\n+ Violating program rules defined by HackerOne or those defined within this Starbucks program policy.\n+ Reports submitted for assets that clearly do not belong to Starbucks.\n+ Reports identifying issues described in our list of Exclusions.\n+ Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions.\n+ SDTO reports without a working proof of concept confirming you have control over the subdomain in question.\n+ 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.\n\n_*Exclusions*_\n *Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance.*\n+ Reports from automated tools or scans.\n+ Reports of credentials exposed by other data breaches / known credential lists.\n+ Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers. \n+ Reports about insecure SSL/TLS configuration.\n+ Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing).\n+ Presence of publicly accessible login pages.\n+ Use of outdated software/library versions.\n+ Use of a known-vulnerable library without a description of an exploit specific to our implementation.\n+ OPTIONS/TRACE HTTP method enabled.\n+ Disclosure of known public files or directories.\n+ Presence of autocomplete functionality in form fields.\n+ Cookies that lack HTTP Only or Secure settings.\n+ Clickjacking and issues only exploitable through clickjacking.\n+ Attacks requiring physical access to a user's device or MITM attacks.\n+ Attacks dependent upon social engineering of Starbucks employees or vendors.\n+ Username enumeration based on login, forgot password, account creation and registration pages.\n+ Password or account recovery policies, such as reset link expiration or password complexity.\n+ Session management concerns such as session duration, concurrent active sessions or session invalidation triggers.\n+ Lack of email address verification during account registration.\n+ Enforcement policies for brute force or account lockout.\n+ Rate-limiting issues.\n+ Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these.\n+ Configuration of or missing security headers.\n+ Mixed content issues.\n+ CSRF on logout.\n+ CSRF on forms that are available to anonymous users.\n+ Self-XSS and issues exploitable only through Self-XSS.\n+ Content spoofing/text injection.\n+ Hyperlink injection in emails using forms available to any user. \n+ Lack of obfuscation in mobile apps.\n+ Absence of certificate pinning.\n+ Lack of jailbreak detection in mobile apps.\n\n______________________________________________________________________________________________________________________\nHelpful Hints\n===============\n______________________________________________________________________________________________________________________\n\n+ Read \u0026 follow the rules.\n+ 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. \n+ 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/.\n+ 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.\n \n\n\n### Appropriate Proof of Concepts\n+ SQLi\u0026nbsp;\u0026nbsp;- A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you.\n+ RCE\u0026nbsp;\u0026nbsp;- A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system.\n+ 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. \n\n\n______________________________________________________________________________________________________________________\nFAQ's\n============\n______________________________________________________________________________________________________________________\n1.\tCan I get Starbucks swag?\n + Starbucks does not currently offer swag.\n2.\tCan Starbucks provide me with a pre-configured test account or Starbucks card(s)?\n + Starbucks does not offer test accounts or test cards.\n3.\tAre all APIs / endpoints initiated by an in-scope mobile or web application eligible for bounty?\n + No. Some APIs accessed by Starbucks applications are not developed or maintained by Starbucks application development teams. If reported through our program and we can act to mitigate a vulnerability, we may triage the report as a valid finding, but it would not be eligible for bounty.\n\n### How to proceed in this situation:\nSet the asset type to the primary application you were testing. Ensure that your write up, includes the specifics for your proof of concept detailing:\n\n + How you tested this\n + Which back end API call(s) had the vulnerability.\n\nStarbucks will review the report and determine whether it remains in-scope and bounty eligible under that primary asset.\n\nA mobile application example can be found within our current scope:\nAndroid Play Store: com.starbucks.singapore\nAssets eligible for bounty referenced directly by this app:\nhttps://mobile.starbucks.com.sg\n\nA 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.\n\n\nThank you for helping keep Starbucks and our users safe!\n======================================\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-11-14T09:16:38.824Z"},{"id":3644111,"new_policy":"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. \n\n###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.\n\n\u0026nbsp;\n______________________________________________________________________________________________________________________\n\nTable of Contents\n============\n______________________________________________________________________________________________________________________\n\n\n### Program\n 1. Legal\n 3. Program Eligibility\n 4. Program Rules\n\n### Report Submissions\n1. What is required when submitting a report?\n2. What happens after you submit a report?\n3. How do I make my report great?\n4. What causes a report to be closed as Informative, Duplicate, N/A, or Spam?\n\n### Helpful Hints\n### FAQ's\n\n\u0026nbsp;\n\n______________________________________________________________________________________________________________________\n\nProgram\n============\n________________________________________\n \n1. Legal\n-----------------\nStarbucks 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.\n \n 2. Program Eligibility\n-----------------\n+ You must agree and adhere to the Program Rules and Legal terms as stated in this policy.\n+ You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty.\n+ You must be available to supply additional information, as needed by our team, to reproduce and triage the issue.\n+ Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability.\n+ Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible.\n+ Starbucks partners (employees) and vendors are not eligible for participation in this program.\n\n 3. Program Rules\n-----------------\n### Do\n+ Read and abide by the program policy.\n+ 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.\n+ Exercise caution when testing to avoid negative impact to customers and the services they depend on.\n+ 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.\n\n### Do NOT\n+ Do not Brute force credentials or guess credentials to gain access to systems.\n+ Do not participate in denial of service attacks.\n+ Do not upload shells or create a backdoor of any kind.\n+ Do not engage in any form of social engineering of Starbucks employees, customers, or vendors.\n+ Do not engage or target any Starbucks employee, customer or vendor during your testing.\n+ Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own. \n+ 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. \n+ Do not publicly disclose vulnerability reports that are not resolved and approved for disclosure by Starbucks.\n+ 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.\n\n______________________________________________________________________________________________________________________\nReport Submissions\n=============\n______________________________________________________________________________________________________________________\n\n \n 1. What is required when submitting a report?\n-----------------\nProvide the information asked for by the new report form, following the instructions there. Some important considerations include:\n+ Title – this should be a quick and clear summary of your issue.\n+ Asset – this should match exactly the asset you are reporting, or “Other”.\n+ Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity.\n+ Weakness – select the most appropriate vulnerability type. \n+ Description – provide all the requested fields.\n\n\n 2. What happens after you submit a report?\n-----------------  \nHackerOne triage 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.\n\nHackerOne triage may close the report as \"Duplicate\", \"Informative\", \"N/A\", \"Spam\", or continue to work with you if more information is needed. They will not move the report to \"Triaged\".\nOnce validated by HackerOne, the triager will assign the report to Starbucks, letting you know in the report with a short message to that effect. \n\nThe Starbucks team will then review your report. We will be working on the issue but may not have enough information to immediately move it from \"New\" to \"Triage\".  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.   \n\nStarbucks will \"Triage\" valid \u0026 eligible reports that 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\".\n \n \n### Rewards\n\nReward amounts are calculated based on the numerical CVSS score assigned to the report.\n\nWe 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.\n\n+ All bounty amounts will be at the discretion of the Starbucks Bug Bounty team.\n+ Reports submitted using methods that violate policy rules will not be eligible for reward.\n+ To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.  \n+ 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.\n+ 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.\n+ Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected.\n\n \n### Disclosure Requests \n\nTo request disclosure, follow the guidelines as outlined by HackerOne: https://docs.hackerone.com/programs/disclosure.html.\n\nOnce Starbucks receives your official disclosure request, we may take the following actions:\n* Redact any sensitive information.\n* Include a Starbucks provided summary.\n* Make adjustments to report metadata to ensure clarity and accuracy, if needed.\n\nOnly reports for in-scope assets that have been closed as 'Resolved' will be considered for disclosure. \nDisclosure requests must be received within 90 days of the report being closed as 'Resolved'.\n\n \n3. How do I make my report great?\n-----------------\nGreat reports lead to quicker resolution and more accurate reward.\n\n+ Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited.\n+ Utilize the CVSS v3 calculator to thoughtfully score your report. \n+ Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding. \n+ 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.\n+ Include your recommendations to resolve the issue.\n+ Be responsive to requests for additional information.\n+ Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved.\n+ Always be polite and respectful to HackerOne and Starbucks team members.\n\nFor more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html\n \n \n \n4. What causes a report to be closed as Informative, Duplicate, N/A or Spam?\n-----------------\nThese 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.\n\n \n### Spam\n+ 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.\n+ 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.\n\n\n \n### Duplicate\n+ 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.\n+ 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.\n\n \n### Informative\n+ Issues with minimal impact or relating to common security practices that are not prioritized for remediation.  \n+ Reports notifying us of broken links or abandoned Social Media accounts.\n+ Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls.\n+ 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.\n+ 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.\n \n### N/A\n+ Violating program rules defined by HackerOne or those defined within this Starbucks program policy.\n+ Reports submitted for assets that clearly do not belong to Starbucks.\n+ Reports identifying issues described in our list of Exclusions.\n+ Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions.\n+ SDTO reports without a working proof of concept confirming you have control over the subdomain in question.\n+ 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.\n\n_*Exclusions*_\n *Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance.*\n+ Reports from automated tools or scans.\n+ Reports of credentials exposed by other data breaches / known credential lists.\n+ Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers. \n+ Reports about insecure SSL/TLS configuration.\n+ Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing).\n+ Presence of publicly accessible login pages.\n+ Use of outdated software/library versions.\n+ Use of a known-vulnerable library without a description of an exploit specific to our implementation.\n+ OPTIONS/TRACE HTTP method enabled.\n+ Disclosure of known public files or directories.\n+ Presence of autocomplete functionality in form fields.\n+ Cookies that lack HTTP Only or Secure settings.\n+ Clickjacking and issues only exploitable through clickjacking.\n+ Attacks requiring physical access to a user's device or MITM attacks.\n+ Attacks dependent upon social engineering of Starbucks employees or vendors.\n+ Username enumeration based on login, forgot password, account creation and registration pages.\n+ Password or account recovery policies, such as reset link expiration or password complexity.\n+ Session management concerns such as session duration, concurrent active sessions or session invalidation triggers.\n+ Lack of email address verification during account registration.\n+ Enforcement policies for brute force or account lockout.\n+ Rate-limiting issues.\n+ Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these.\n+ Configuration of or missing security headers.\n+ Mixed content issues.\n+ CSRF on logout.\n+ CSRF on forms that are available to anonymous users.\n+ Self-XSS and issues exploitable only through Self-XSS.\n+ Content spoofing/text injection.\n+ Hyperlink injection in emails using forms available to any user. \n+ Lack of obfuscation in mobile apps.\n+ Absence of certificate pinning.\n+ Lack of jailbreak detection in mobile apps.\n\n______________________________________________________________________________________________________________________\nHelpful Hints\n===============\n______________________________________________________________________________________________________________________\n\n+ Read \u0026 follow the rules.\n+ 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. \n+ 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/.\n+ 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.\n \n\n\n### Appropriate Proof of Concepts\n+ SQLi\u0026nbsp;\u0026nbsp;- A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you.\n+ RCE\u0026nbsp;\u0026nbsp;- A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system.\n+ 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. \n\n\n______________________________________________________________________________________________________________________\nFAQ's\n============\n______________________________________________________________________________________________________________________\n1.\tCan I get Starbucks swag?\n + Starbucks does not currently offer swag.\n2.\tCan Starbucks provide me with a pre-configured test account or Starbucks card(s)?\n + Starbucks does not offer test accounts or test cards.\n\nThank you for helping keep Starbucks and our users safe!\n======================================\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-10-22T00:12:21.689Z"},{"id":3642926,"new_policy":"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. \n\n###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.\n\n\u0026nbsp;\n______________________________________________________________________________________________________________________\n\nTable of Contents\n============\n______________________________________________________________________________________________________________________\n\n\n### Program\n 1. Legal\n 3. Program Eligibility\n 4. Program Rules\n\n### Report Submissions\n1. What is required when submitting a report?\n2. What happens after you submit a report?\n3. How do I make my report great?\n4. What causes a report to be closed as Informative, Duplicate, N/A, or Spam?\n\n### Helpful Hints\n### FAQ's\n\n\u0026nbsp;\n\n______________________________________________________________________________________________________________________\n\nProgram\n============\n________________________________________\n \n1. Legal\n-----------------\nStarbucks 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.\n \n 2. Program Eligibility\n-----------------\n+ You must agree and adhere to the Program Rules and Legal terms as stated in this policy.\n+ You must be the first to submit a sufficiently reproducible report for an issue in order to be eligible for a bounty.\n+ You must be available to supply additional information, as needed by our team, to reproduce and triage the issue.\n+ Zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability.\n+ Out-of-scope vulnerability reports may be addressed as a form of vulnerability disclosure but will generally not be considered reward eligible.\n+ Starbucks partners (employees) and vendors are not eligible for participation in this program.\n\n 3. Program Rules\n-----------------\n### Do\n+ Read and abide by the program policy.\n+ 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.\n+ Exercise caution when testing to avoid negative impact to customers and the services they depend on.\n+ 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.\n\n### Do NOT\n+ Do not Brute force credentials or guess credentials to gain access to systems.\n+ Do not participate in denial of service attacks.\n+ Do not upload shells or create a backdoor of any kind.\n+ Do not engage in any form of social engineering of Starbucks employees, customers, or vendors.\n+ Do not engage or target any Starbucks employee, customer or vendor during your testing.\n+ Do not attempt to extract, download, or otherwise exfiltrate data which you believe may have PII other than your own. \n+ 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. \n+ Do not publicly disclose vulnerability reports that are not resolved and approved for disclosure by Starbucks.\n+ 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.\n\n______________________________________________________________________________________________________________________\nReport Submissions\n=============\n______________________________________________________________________________________________________________________\n\n \n 1. What is required when submitting a report?\n-----------------\nProvide the information asked for by the new report form, following the instructions there. Some important considerations include:\n+ Title – this should be a quick and clear summary of your issue.\n+ Asset – this should match exactly the asset you are reporting, or “Other”\n+ Severity – the CVSS calculator is used to evaluate severity and bounty, so to avoid disappointment, be honest and critical when scoring severity.\n+ Weakness – select the most appropriate vulnerability type. \n+ Description – provide all the requested fields.\n\n\n 2. What happens after you submit a report?\n-----------------  \nHackerOne triage 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.\n\nHackerOne triage may close the report as \"Duplicate\", \"Informative\", \"N/A\", \"Spam\", or continue to work with you if more information is needed. They will not move the report to \"Triaged\".\nOnce validated by HackerOne, the triager will assign the report to Starbucks, letting you know in the report with a short message to that effect. \n\nThe Starbucks team will then review your report. We will be working on the issue but may not have enough information to immediately move it from \"New\" to \"Triage\".  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.   \n\nStarbucks will \"Triage\" valid \u0026 eligible reports that 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\".\n \n \n### Rewards\n\nReward amounts are calculated based on the numerical CVSS score assigned to the report.\n\nWe 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.\n\n+ All bounty amounts will be at the discretion of the Starbucks Bug Bounty team.\n+ Reports submitted using methods that violate policy rules will not be eligible for reward.\n+ To be eligible for a reward, the report must be for a reward eligible asset as defined in the scope section of our policy.  \n+ 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.\n+ 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.\n+ Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected.\n\n \n### Disclosure Requests \n\nTo request disclosure, follow the guidelines as outlined by HackerOne: https://docs.hackerone.com/programs/disclosure.html.\n\nOnce Starbucks receives your official disclosure request, we may take the following actions:\n* Redact any sensitive information.\n* Include a Starbucks provided summary.\n* Make adjustments to report metadata to ensure clarity and accuracy, if needed.\n\nOnly reports for in-scope assets that have been closed as 'Resolved' will be considered for disclosure.\n\n \n3. How do I make my report great?\n-----------------\nGreat reports lead to quicker resolution and more accurate reward.\n\n+ Clearly describe the impact your finding would have on Starbucks assets or Starbucks customers and how this could be exploited.\n+ Utilize the CVSS v3 calculator to thoughtfully score your report. \n+ Include detailed and easy to follow reproduction steps along with screenshots and videos to support your finding. \n+ 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.\n+ Include your recommendations to resolve the issue.\n+ Be responsive to requests for additional information.\n+ Participate in validation and testing efforts once the Starbucks team advises the issue has been resolved.\n+ Always be polite and respectful to HackerOne and Starbucks team members.\n\nFor more information on drafting high quality reports, be sure to study this post by HackerOne: https://docs.hackerone.com/hackers/quality-reports.html\n \n \n \n4. What causes a report to be closed as Informative, Duplicate, N/A or Spam?\n-----------------\nThese 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.\n\n \n### Spam\n+ 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.\n+ 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\n\n\n \n### Duplicate\n+ 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.\n+ 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.\n\n \n### Informative\n+ Issues with minimal impact or relating to common security practices that are not prioritized for remediation.  \n+ Reports notifying us of broken links or abandoned Social Media accounts.\n+ Reports submissions might have a perceived security impact externally but internally Starbucks may have compensating controls.\n+ 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.\n+ 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.\n \n### N/A\n+ Violating program rules defined by HackerOne or those defined within this Starbucks program policy.\n+ Reports submitted for assets that clearly do not belong to Starbucks.\n+ Reports identifying issues described in our list of Exclusions.\n+ Reports describing issues are not exploitable, require social engineering, or depend on other unlikely interactions.\n+ SDTO reports without a working proof of concept confirming you have control over the subdomain in question\n+ 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.\n\n_*Exclusions*_\n *Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance.*\n+ Reports from automated tools or scans.\n+ Reports of credentials exposed by other data breaches / known credential lists.\n+ Mail configuration issues including SPF, DKIM, DMARC settings and reports pertaining to external mail service providers. \n+ Reports about insecure SSL/TLS configuration.\n+ Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing).\n+ Presence of publicly accessible login pages.\n+ Use of outdated software/library versions.\n+ Use of a known-vulnerable library without a description of an exploit specific to our implementation\n+ OPTIONS/TRACE HTTP method enabled.\n+ Disclosure of known public files or directories.\n+ Presence of autocomplete functionality in form fields.\n+ Cookies that lack HTTP Only or Secure settings.\n+ Clickjacking and issues only exploitable through clickjacking.\n+ Attacks requiring physical access to a user's device or MITM attacks.\n+ Attacks dependent upon social engineering of Starbucks employees or vendors.\n+ Username enumeration based on login, forgot password, account creation and registration pages.\n+ Password or account recovery policies, such as reset link expiration or password complexity.\n+ Session management concerns such as session duration, concurrent active sessions or session invalidation triggers.\n+ Lack of email address verification during account registration.\n+ Enforcement policies for brute force or account lockout.\n+ Rate-limiting issues.\n+ Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these.\n+ Configuration of or missing security headers.\n+ Mixed content issues.\n+ CSRF on logout.\n+ CSRF on forms that are available to anonymous users.\n+ Self-XSS and issues exploitable only through Self-XSS.\n+ Content spoofing/text injection.\n+ Hyperlink injection in emails using forms available to any user. \n+ Lack of obfuscation in mobile apps.\n+ Absence of certificate pinning.\n+ Lack of jailbreak detection in mobile apps.\n\n______________________________________________________________________________________________________________________\nHelpful Hints\n===============\n______________________________________________________________________________________________________________________\n\n+ Read \u0026 follow the rules.\n+ 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. \n+ 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/.\n+ If your motivation is financial compensation, you are more likely to 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.\n \n\n\n### Appropriate Proof of Concepts\n+ SQLi\u0026nbsp;\u0026nbsp;- A sleep command (or equivalent) is often enough. Do not attempt to read or modify data that does not belong to you.\n+ RCE\u0026nbsp;\u0026nbsp;- A whoami (or equivalent) command is enough. Do not perform additional actions. Do not alter or delete any files on the system.\n+ 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. \n\n\n______________________________________________________________________________________________________________________\nFAQ's\n============\n______________________________________________________________________________________________________________________\n1.\tCan I get Starbucks swag?\n + Starbucks does not currently offer swag.\n2.\tCan Starbucks provide me with a pre-configured test account or Starbucks card(s)?\n + Starbucks does not offer test accounts or test cards.\n\nThank you for helping keep Starbucks and our users safe!\n======================================\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-09-28T16:48:02.017Z"},{"id":3588645,"new_policy":"Starbucks believes in a program that fosters collaboration amongst security professionals to help protect our systems and customers’ personal information from malicious activity due to vulnerabilities against our networks, web and mobile applications and set security policies across our organization. We treat the security and safety of our customers’ personal information with utmost importance.\nFor the protection of our customers, Starbucks does not disclose, discuss or confirm security matters until comprehensively investigating, diagnosing and fixing any known issues.\n\n# Program Rules\n* Do not intentionally harm the experience or usefulness of the service to others, including degradation of services \u0026 denial of service attacks.\n* Do not attempt to view, modify, or damage data belonging to others.\n* Do not disclose the reported vulnerability to others until we’ve had reasonable time to address it.\n\n# Bounty Eligibility\n* You must agree and adhere to the Program Rules and Legal terms as stated in this policy.\n* You must be the first to report the issue in order to be eligible for bounty.\n* You must be available to supply additional information, as needed by our team, to reproduce and triage the issue.\n* Starbucks Partners are not eligible for participation in this program.\n\nPlease consider the following when reporting issues:\n\nMany of our sites share a common platform. Because of this, a vulnerability reported on one domain may exist on another domain if the sites are in the same 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 ask that you take the time to replicate the issue in other sites, and if replicating, please include all occurrences in one report instead of submitting them as multiple reports. 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.\n\n\n# Exclusions\n* Denial of Service attacks.\n* Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing) .\n* Disclosure of known public files or directories.\n* Use of outdated software / library versions.\n* Use of a known-vulnerable library without a description of an exploit specific to our implementation\n* OPTIONS / TRACE HTTP method enabled.\n* CSRF on logout.\n* CSRF on forms that are available to anonymous users.\n* Cookies that lack HTTP Only or Secure settings for non-sensitive data.\n* Self-XSS and issues exploitable only through Self-XSS.\n* Reports from automated tools or scans.\n* Attacks requiring physical access to a user's device or MITM attacks.\n* Attacks dependent upon social engineering of Starbucks employees or vendors.\n* Username enumeration based on login, forgot password, account creation and registration pages.\n* Enforcement policies for brute force or account lockout.\n* Reports about insecure SSL / TLS configuration.\n* Clickjacking and issues only exploitable through clickjacking.\n* Mail configuration issues including SPF, DKIM, DMARC settings.\n* Password or account recovery policies, such as reset link expiration or password complexity.\n* Presence of autocomplete functionality in form fields.\n* Publicly accessible login panels.\n* Lack of email address verification during account registration .\n* Rate-limiting issues.\n* Content spoofing / text injection.\n* Missing security headers .\n* Mixed content issues.\n* Issues related to active sessions after password changes.\n* Hyperlink injection in emails using forms available to any user. \n* Reports of credentials exposed by other data breaches / known credential lists.\n* Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these.\n* Lack of obfuscation in mobile apps.\n* Absence of certificate pinning.\n* Lack of jailbreak detection in mobile apps.\n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance.*\n\n#Rewards\nAll bounty amounts will be at the discretion of the Starbucks Bug Bounty team and will be evaluated for severity, impact, and quality of the report. There could be submissions for which we accept the risk and will not fix.\n\n# What to include in your report \nA well-written report will allow us to more quickly and accurately triage your submission.\n* A clear description of the issue, including the impact you believe it has on the user, Starbucks, others.\n* Specific reproduction steps including the environment used for testing (browsers, devices, tools, configuration) and any accounts used during testing.\n* Clear and valid security impact of the issue.\n* Your recommendations to resolve the issue.  \n\n# Legal\nStarbucks 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.   \n\nThank you for helping keep Starbucks and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-09-13T17:23:21.014Z"},{"id":3584167,"new_policy":"Starbucks believes in a program that fosters collaboration amongst security professionals to help protect our systems and customers’ personal information from malicious activity due to vulnerabilities against our networks, web and mobile applications and set security policies across our organization. We treat the security and safety of our customers’ personal information with utmost importance.\nFor the protection of our customers, Starbucks does not disclose, discuss or confirm security matters until comprehensively investigating, diagnosing and fixing any known issues.\n\n# Program Rules\n* Do not intentionally harm the experience or usefulness of the service to others, including degradation of services \u0026 denial of service attacks.\n* Do not attempt to view, modify, or damage data belonging to others.\n* Do not disclose the reported vulnerability to others until we’ve had reasonable time to address it.\n\n# Bounty Eligibility\n* You must agree and adhere to the Program Rules and Legal terms as stated in this policy.\n* You must be the first to report the issue in order to be eligible for bounty.\n* You must be available to supply additional information, as needed by our team, to reproduce and triage the issue.\n* Starbucks Partners are not eligible for participation in this program.\n\nPlease consider the following when reporting issues:\n\nMany of our sites share a common platform. Because of this, a vulnerability reported on one domain may exist on another domain if the sites are in the same 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 ask that you take the time to replicate the issue in other sites, and if replicating, please include all occurrences in one report instead of submitting them as multiple reports. 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.\n\n\n# Exclusions\n* Denial of Service attacks.\n* Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing) .\n* Disclosure of known public files or directories.\n* Use of outdated software / library versions.\n* Use of a known-vulnerable library without a description of an exploit specific to our implementation\n* OPTIONS / TRACE HTTP method enabled.\n* CSRF on logout.\n* CSRF on forms that are available to anonymous users.\n* Cookies that lack HTTP Only or Secure settings for non-sensitive data.\n* Self-XSS and issues exploitable only through Self-XSS.\n* Reports from automated tools or scans.\n* Attacks requiring physical access to a user's device.\n* Attacks dependent upon social engineering of Starbucks employees or vendors.\n* Username enumeration based on login, forgot password, account creation and registration pages.\n* Enforcement policies for brute force or account lockout.\n* Reports about insecure SSL / TLS configuration.\n* Clickjacking and issues only exploitable through clickjacking.\n* Mail configuration issues including SPF, DKIM, DMARC settings.\n* Password or account recovery policies, such as reset link expiration or password complexity.\n* Presence of autocomplete functionality in form fields.\n* Publicly accessible login panels.\n* Lack of email address verification during account registration .\n* Rate-limiting issues.\n* Content spoofing / text injection.\n* Missing security headers .\n* Mixed content issues.\n* Issues related to active sessions after password changes.\n* Hyperlink injection in emails using forms available to any user. \n* Reports of credentials exposed by other data breaches / known credential lists.\n* Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and/or wildcard. presence/misconfiguration in these.\n* Lack of obfuscation in mobile apps.\n* Absence of certificate pinning.\n* Lack of jailbreak detection in mobile apps.\n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on the evaluated severity of reported vulnerabilities and risk acceptance.*\n\n#Rewards\nAll bounty amounts will be at the discretion of the Starbucks Bug Bounty team and will be evaluated for severity, impact, and quality of the report. There could be submissions for which we accept the risk and will not fix.\n\n# What to include in your report \nA well-written report will allow us to more quickly and accurately triage your submission.\n* A clear description of the issue, including the impact you believe it has on the user, Starbucks, others.\n* Specific reproduction steps including the environment used for testing (browsers, devices, tools, configuration) and any accounts used during testing.\n* Clear and valid security impact of the issue.\n* Your recommendations to resolve the issue.  \n\n# Legal\nStarbucks 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.   \n\nThank you for helping keep Starbucks and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-07-31T00:03:52.401Z"},{"id":3543920,"new_policy":"Starbucks believes in a program that fosters collaboration amongst security professionals to help protect our customers’ personal information from malicious activity due to vulnerabilities against our networks, web and mobile applications and set security policies across our organization. We treat the security and safety of our customers’ personal information with the utmost importance.\nFor the protection of our customers, Starbucks does not disclose, discuss or confirm security matters until comprehensively investigating, diagnosing and fixing any known issues.\n\n# Program Rules\n* Do not intentionally harm the experience or usefulness of the service to others, including degradation of services \u0026 denial of service attacks.\n* Do not attempt to view, modify, or damage data belonging to others\n* Do not disclose the reported vulnerability to others until we’ve had reasonable time to address it.\n\n# Bounty Eligibility\n* You must agree and adhere to the Program Rules and Legal terms as stated in this policy.\n* You must be the first to report the issue in order to be eligible for bounty*.\n* You must be available to supply additional information, as needed by our team, to reproduce and triage the issue.\n* Starbucks Partners are not eligible for participation in this program\n\n**Please note that Starbucks has been managing a bug bounty program independent of HackerOne for some time. Reports submitted to our existing program have been submitted outside of the HackerOne platform and, as such, we may not always be able to link to a duplicate report. We appreciate your understanding in this matter as we transition our program to the HackerOne platform.*\n\n# Targets Eligible for Reward\nCurrently, we offer monetary rewards only for the properties listed below.\nSubdomains not specifically listed are not included in the Targets Eligible for Reward.  \nSome unique issue types not related to the domains listed below, such as reports of subdomain takeovers, may also be eligible for reward.\nWe may modify this list over time, so be sure to visit our policy often to review any updates.\n\nIf you have found a vulnerability in a Starbucks site or app not contained within this list, you can still submit, and Starbucks will triage the report.\nThese types of reports will not result in a monetary reward but valid reports that are resolved can improve your reputation score on the HackerOne platform.\n\n* [www.starbucks.com](http://www.starbucks.com)\n* [www.starbucks.ca](http://www.starbucks.ca)\n* [www.starbucks.com.br](http://www.starbucks.com.br)\n* [www.starbucks.fr](http://www.starbucks.com.fr)\n* [www.starbucks.co.uk](http://www.starbucks.com.co.uk)\n* [www.starbucks.de](http://www.starbucks.com.de)\n* [store.starbucks.com](http://store.starbucks.com)\n* [store.starbucks.ca](http://store.starbucks.ca)\n* [store.starbucks.fr](http://store.starbucks.fr)\n* [store.starbucks.co.uk](http://store.starbucks.co.uk)\n* [store.starbucks.de](http://store.starbucks.de)\n* [www.teavana.com](http://www.teavana.com)\n* Starbucks [iOS](https://itunes.apple.com/app/starbucks/id331177714) \u0026 [Android](https://play.google.com/store/apps/details?id=com.starbucks.mobilecard) apps for US, CA, BR, FR, UK, DE\n* [Starbucks app for Windows] (https://www.starbucks.com/coffeehouse/mobile-apps/starbucks-app-for-windows)\n\nMany of our sites share a common platform. Because of this, a vulnerability reported on one domain may exist on another domain if the issue exists in the shared platform itself. For example, an issue reported for starbucks.com may also present in the exact same way on starbucks.ca and the issue will be resolved on both sites with the same fix. We ask that you take the time to try to confirm this first, and include the other vulnerable locations in one report rather than submitting multiple reports. In these cases, we treat the issue as one bug and will close out others as duplicates. Rest assured, we do take the existence of a vulnerability present on multiple sites into consideration during reward time.\n\nPlease consider the following when reporting issues:\n- Many of our eCommerce sites share a common platform including: teavana.com, store.starbucks.*, and some shop.starbucks.* sites. Some bugs may present in only one of the sites, some may present in multiple with the same root cause.\n- Many of our other www.starbucks.* sties share a common platform, including: starbucks.com, starbucks.ca, starbucks.de, starbucks.fr, starbucks.com.br, starbucks.co.uk. Some bugs may present in only one of the sites, some may present in multiple with the same root cause.\n- It speeds up the triage process if you include in your one report other locations where the same bug is present.\n- We do consider the number of locations where the vulnerability exists when awarding.\n- When in doubt, please file a single report and write down your thoughts. If we think you found different vulnerabilities, we’ll be more than happy to let you file another bug so your reputation and signal will get another boost.\n\n# Exclusions\n* Denial of Service attacks\n* Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing) \n* Disclosure of known public files or directories\n* Outdated software / library versions\n* OPTIONS / TRACE HTTP method enabled\n* CSRF on logout\n* CSRF on forms that are available to anonymous users\n* Cookies that lack HTTP Only or Secure settings for non-sensitive data\n* Self-XSS and issues exploitable only through Self-XSS\n* Reports resulting from automated scanning utilities without additional details or a POC demonstrating a specific exploit\n* Attacks requiring physical access to a user's device\n* Attacks dependent upon social engineering of Starbucks employees or vendors.\n* Username enumeration based on login or forgot password pages.\n* Enforcement policies for brute force or account lockout\n* SSL/TLS best practices\n* Clickjacking, without additional details demonstrating a specific exploit\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Use of a known-vulnerable library without a description of an exploit specific to our implementation\n* Password and account recovery policies\n* Presence of autocomplete functionality in form fields\n* Publicly accessible login panels\n* Lack of email address verification during account registration\n* Rate-limiting issues\n* Content spoofing / text injection\n* Missing security headers without additional details or a POC demonstrating a specific exploit \n* Mixed content issues\n* Attacks requiring physical access to device or MiTM\n* Issues related to active sessions after password changes.\n* Hyperlink injection in emails using forms available to any user\n* Host Header Injection\n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on evaluated severity of reported vulnerabilities and risk acceptance.*\n\n#Rewards\nAll bounty amounts will be at the discretion of the Starbucks Bug Bounty team, which will be evaluated for severity, impact, and quality of the report to determine the bounty level. There could be submissions which we accept the risk and will not fix.\n* __Critical__: Bounty min of $4000.00.\nExamples: privilege escalation, remote code execution, SQL injection (depending on impact), unauthorized access to account data.\n\n* __High__: Bounty min of $500.00.\nExamples: Stored XSS against another user, insecure direct object reference to unauthorized data, SQL injection (depending on impact).\n* __Medium__: Bounty min of $250.00\nExamples: XSS (depending on impact), CSRF (depending on impact).\n* __Low__: Bounty min of $100.00\nExamples: XSS (depending on impact), CSRF (depending on impact), Invalidated redirects (depending on impact).\n\n# What to include in your report \nA well written report will allow us to more quickly and accurately triage your submission.\n* A clear description of the issue, including the impact you believe it has to the user, Starbucks, others.\n* Specific reproduction steps including the environment used for testing (browsers, devices, tools, configuration) and any accounts used during testing.\n* Your recommendations to resolve the issue.\n\n# Legal\nStarbucks 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.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-12-30T07:02:48.056Z"},{"id":3542660,"new_policy":"Starbucks believes in a program that fosters collaboration amongst security professionals to help protect our customers’ personal information from malicious activity due to vulnerabilities against our networks, web and mobile applications and set security policies across our organization. We treat the security and safety of our customers’ personal information with the utmost importance.\nFor the protection of our customers, Starbucks does not disclose, discuss or confirm security matters until comprehensively investigating, diagnosing and fixing any known issues.\n\n# Program Rules\n* Do not intentionally harm the experience or usefulness of the service to others, including degradation of services \u0026 denial of service attacks.\n* Do not attempt to view, modify, or damage data belonging to others\n* Do not disclose the reported vulnerability to others until we’ve had reasonable time to address it.\n\n# Bounty Eligibility\n* You must agree and adhere to the Program Rules and Legal terms as stated in this policy.\n* You must be the first to report the issue in order to be eligible for bounty*.\n* You must be available to supply additional information, as needed by our team, to reproduce and triage the issue.\n* Starbucks Partners are not eligible for participation in this program\n\n**Please note that Starbucks has been managing a bug bounty program independent of HackerOne for some time. Reports submitted to our existing program have been submitted outside of the HackerOne platform and, as such, we may not always be able to link to a duplicate report. We appreciate your understanding in this matter as we transition our program to the HackerOne platform.*\n\n# Targets Eligible for Reward\nCurrently, we offer monetary rewards only for the properties listed below.\nSubdomains not specifically listed are not included in the Targets Eligible for Reward.  \nSome unique issue types not related to the domains listed below, such as reports of subdomain takeovers, may also be eligible for reward.\nWe may modify this list over time, so be sure to visit our policy often to review any updates.\n\nIf you have found a vulnerability in a Starbucks site or app not contained within this list, you can still submit, and Starbucks will triage the report.\nThese types of reports will not result in a monetary reward but valid reports that are resolved can improve your reputation score on the HackerOne platform.\n\n* [www.starbucks.com](http://www.starbucks.com)\n* [www.starbucks.ca](http://www.starbucks.ca)\n* [www.starbucks.com.br](http://www.starbucks.com.br)\n* [www.starbucks.fr](http://www.starbucks.com.fr)\n* [www.starbucks.co.uk](http://www.starbucks.com.co.uk)\n* [www.starbucks.de](http://www.starbucks.com.de)\n* [store.starbucks.com](http://store.starbucks.com)\n* [store.starbucks.ca](http://store.starbucks.ca)\n* [store.starbucks.fr](http://store.starbucks.fr)\n* [store.starbucks.co.uk](http://store.starbucks.co.uk)\n* [store.starbucks.de](http://store.starbucks.de)\n* [www.teavana.com](http://www.teavana.com)\n* Starbucks [iOS](https://itunes.apple.com/app/starbucks/id331177714) \u0026 [Android](https://play.google.com/store/apps/details?id=com.starbucks.mobilecard) apps for US, CA, BR, FR, UK, DE\n* [Starbucks app for Windows] (https://www.starbucks.com/coffeehouse/mobile-apps/starbucks-app-for-windows)\n\nMany of our sites share a common platform. Because of this, a vulnerability reported on one domain may exist on another domain if the issue exists in the shared platform itself. For example, an issue reported for starbucks.com may also present in the exact same way on starbucks.ca and the issue will be resolved on both sites with the same fix. We ask that you take the time to try to confirm this first, and include the other vulnerable locations in one report rather than submitting multiple reports. In these cases, we treat the issue as one bug and will close out others as duplicates. Rest assured, we do take the existence of a vulnerability present on multiple sites into consideration during reward time.\n\nPlease consider the following when reporting issues:\n- Many of our eCommerce sites share a common platform including: teavana.com, store.starbucks.*, and some shop.starbucks.* sites. Some bugs may present in only one of the sites, some may present in multiple with the same root cause.\n- Many of our other www.starbucks.* sties share a common platform, including: starbucks.com, starbucks.ca, starbucks.de, starbucks.fr, starbucks.com.br, starbucks.co.uk. Some bugs may present in only one of the sites, some may present in multiple with the same root cause.\n- It speeds up the triage process if you include in your one report other locations where the same bug is present.\n- We do consider the number of locations where the vulnerability exists when awarding.\n- When in doubt, please file a single report and write down your thoughts. If we think you found different vulnerabilities, we’ll be more than happy to let you file another bug so your reputation and signal will get another boost.\n\n# Exclusions\n* Denial of Service attacks\n* Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing) \n* Disclosure of known public files or directories\n* Outdated software / library versions\n* OPTIONS / TRACE HTTP method enabled\n* CSRF on logout\n* CSRF on forms that are available to anonymous users\n* Cookies that lack HTTP Only or Secure settings for non-sensitive data\n* Self-XSS and issues exploitable only through Self-XSS\n* Reports resulting from automated scanning utilities without additional details or a POC demonstrating a specific exploit\n* Attacks requiring physical access to a user's device\n* Attacks dependent upon social engineering of Starbucks employees or vendors.\n* Username enumeration based on login or forgot password pages.\n* Enforcement policies for brute force or account lockout\n* SSL/TLS best practices\n* Clickjacking, without additional details demonstrating a specific exploit\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Use of a known-vulnerable library without a description of an exploit specific to our implementation\n* Password and account recovery policies\n* Presence of autocomplete functionality in form fields\n* Publicly accessible login panels\n* Lack of email address verification during account registration\n* Rate-limiting issues\n* Content spoofing / text injection\n* Missing security headers without additional details or a POC demonstrating a specific exploit \n* Mixed content issues\n* Attacks requiring physical access to device or MiTM\n* Issues related to active sessions after password changes.\n* Hyperlink injection in emails using forms available to any user\n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on evaluated severity of reported vulnerabilities and risk acceptance.*\n\n#Rewards\nAll bounty amounts will be at the discretion of the Starbucks Bug Bounty team, which will be evaluated for severity, impact, and quality of the report to determine the bounty level. There could be submissions which we accept the risk and will not fix.\n* __Critical__: Bounty min of $4000.00.\nExamples: privilege escalation, remote code execution, SQL injection (depending on impact), unauthorized access to account data.\n\n* __High__: Bounty min of $500.00.\nExamples: Stored XSS against another user, insecure direct object reference to unauthorized data, SQL injection (depending on impact).\n* __Medium__: Bounty min of $250.00\nExamples: XSS (depending on impact), CSRF (depending on impact).\n* __Low__: Bounty min of $100.00\nExamples: XSS (depending on impact), CSRF (depending on impact), Invalidated redirects (depending on impact).\n\n# What to include in your report \nA well written report will allow us to more quickly and accurately triage your submission.\n* A clear description of the issue, including the impact you believe it has to the user, Starbucks, others.\n* Specific reproduction steps including the environment used for testing (browsers, devices, tools, configuration) and any accounts used during testing.\n* Your recommendations to resolve the issue.\n\n# Legal\nStarbucks 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.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-12-03T00:20:06.019Z"},{"id":3542652,"new_policy":"Starbucks believes in a program that fosters collaboration amongst security professionals to help protect our customers’ personal information from malicious activity due to vulnerabilities against our networks, web and mobile applications and set security policies across our organization. We treat the security and safety of our customers’ personal information with the utmost importance.\nFor the protection of our customers, Starbucks does not disclose, discuss or confirm security matters until comprehensively investigating, diagnosing and fixing any known issues.\n\n# Program Rules\n* Do not intentionally harm the experience or usefulness of the service to others, including degradation of services \u0026 denial of service attacks.\n* Do not attempt to view, modify, or damage data belonging to others\n* Do not disclose the reported vulnerability to others until we’ve had reasonable time to address it.\n\n# Bounty Eligibility\n* You must agree and adhere to the Program Rules and Legal terms as stated in this policy.\n* You must be the first to report the issue in order to be eligible for bounty*.\n* You must be available to supply additional information, as needed by our team, to reproduce and triage the issue.\n* Starbucks Partners are not eligible for participation in this program\n\n**Please note that Starbucks has been managing a bug bounty program independent of HackerOne for some time. Reports submitted to our existing program have been submitted outside of the HackerOne platform and, as such, we may not always be able to link to a duplicate report. We appreciate your understanding in this matter as we transition our program to the HackerOne platform.*\n\n# Targets Eligible for Reward\nCurrently, we offer monetary rewards only for the properties listed below.\nSubdomains not specifically listed are not included in the Targets Eligible for Reward.  \nSome unique issue types not related to the domains listed below, such as reports of subdomain takeovers, may also be eligible for reward.\nWe may modify this list over time, so be sure to visit our policy often to review any updates.\n\nIf you have found a vulnerability in a Starbucks site or app not contained within this list, you can still submit, and Starbucks will triage the report.\nThese types of reports will not result in a monetary reward but valid reports that are resolved can improve your reputation score on the HackerOne platform.\n\n* [www.starbucks.com](http://www.starbucks.com)\n* [www.starbucks.ca](http://www.starbucks.ca)\n* [www.starbucks.com.br](http://www.starbucks.com.br)\n* [www.starbucks.fr](http://www.starbucks.com.fr)\n* [www.starbucks.co.uk](http://www.starbucks.com.co.uk)\n* [www.starbucks.de](http://www.starbucks.com.de)\n* [store.starbucks.com](http://store.starbucks.com)\n* [store.starbucks.ca](http://store.starbucks.ca)\n* [store.starbucks.fr](http://store.starbucks.fr)\n* [store.starbucks.co.uk](http://store.starbucks.co.uk)\n* [store.starbucks.de](http://store.starbucks.de)\n* [www.teavana.com](http://www.teavana.com)\n* Starbucks [iOS](https://itunes.apple.com/app/starbucks/id331177714) \u0026 [Android](https://play.google.com/store/apps/details?id=com.starbucks.mobilecard) apps for US, CA, BR, FR, UK, DE\n* [Starbucks app for Windows] (https://www.starbucks.com/coffeehouse/mobile-apps/starbucks-app-for-windows)\n\nMany of our sites share a common platform. Because of this, a vulnerability reported on one domain may exist on another domain if the issue exists in the shared platform itself. For example, an issue reported for starbucks.com may also present in the exact same way on starbucks.ca and the issue will be resolved on both sites with the same fix. We ask that you take the time to try to confirm this first, and include the other vulnerable locations in one report rather than submitting multiple reports. In these cases, we treat the issue as one bug and will close out others as duplicates. Rest assured, we do take the existence of a vulnerability present on multiple sites into consideration during reward time.\n\nPlease consider the following when reporting issues:\n- Many of our eCommerce sites share a common platform including: teavana.com, store.starbucks.*, and some shop.starbucks.* sites. Some bugs may present in only one of the sites, some may present in multiple with the same root cause.\n- Many of our other www.starbucks.* sties share a common platform, including: starbucks.com, starbucks.ca, starbucks.de, starbucks.fr, starbucks.com.br, starbucks.co.uk. Some bugs may present in only one of the sites, some may present in multiple with the same root cause.\n- It speeds up the triage process if you include in your one report other locations where the same bug is present.\n- We do consider the number of locations where the vulnerability exists when awarding.\n- When in doubt, please file a single report and write down your thoughts. If we think you found different vulnerabilities, we’ll be more than happy to let you file another bug so your reputation and signal will get another boost.\n\n# Exclusions\n* Denial of Service attacks\n* Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing) \n* Disclosure of known public files or directories\n* Outdated software / library versions\n* OPTIONS / TRACE HTTP method enabled\n* CSRF on logout\n* CSRF on forms that are available to anonymous users\n* Cookies that lack HTTP Only or Secure settings for non-sensitive data\n* Self-XSS and issues exploitable only through Self-XSS\n* Reports resulting from automated scanning utilities without additional details or a POC demonstrating a specific exploit\n* Attacks requiring physical access to a user's device\n* Attacks dependent upon social engineering of Starbucks employees or vendors.\n* Username enumeration based on login or forgot password pages.\n* Enforcement policies for brute force or account lockout\n* SSL/TLS best practices\n* Clickjacking, without additional details demonstrating a specific exploit\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Use of a known-vulnerable library without a description of an exploit specific to our implementation\n* Password and account recovery policies\n* Presence of autocomplete functionality in form fields\n* Publicly accessible login panels\n* Lack of email address verification during account registration\n* Rate-limiting issues\n* Content spoofing / text injection\n* Missing security headers without additional details or a POC demonstrating a specific exploit \n* Mixed content issues\n* Attacks requiring physical access to device or MiTM\n* Issues related to active sessions after password changes.\n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on evaluated severity of reported vulnerabilities and risk acceptance.*\n\n#Rewards\nAll bounty amounts will be at the discretion of the Starbucks Bug Bounty team, which will be evaluated for severity, impact, and quality of the report to determine the bounty level. There could be submissions which we accept the risk and will not fix.\n* __Critical__: Bounty min of $4000.00.\nExamples: privilege escalation, remote code execution, SQL injection (depending on impact), unauthorized access to account data.\n\n* __High__: Bounty min of $500.00.\nExamples: Stored XSS against another user, insecure direct object reference to unauthorized data, SQL injection (depending on impact).\n* __Medium__: Bounty min of $250.00\nExamples: XSS (depending on impact), CSRF (depending on impact).\n* __Low__: Bounty min of $100.00\nExamples: XSS (depending on impact), CSRF (depending on impact), Invalidated redirects (depending on impact).\n\n# What to include in your report \nA well written report will allow us to more quickly and accurately triage your submission.\n* A clear description of the issue, including the impact you believe it has to the user, Starbucks, others.\n* Specific reproduction steps including the environment used for testing (browsers, devices, tools, configuration) and any accounts used during testing.\n* Your recommendations to resolve the issue.\n\n# Legal\nStarbucks 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.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-12-02T20:48:29.752Z"},{"id":3542535,"new_policy":"Starbucks believes in a program that fosters collaboration amongst security professionals to help protect our customers’ personal information from malicious activity due to vulnerabilities against our networks, web and mobile applications and set security policies across our organization. We treat the security and safety of our customers’ personal information with the utmost importance.\nFor the protection of our customers, Starbucks does not disclose, discuss or confirm security matters until comprehensively investigating, diagnosing and fixing any known issues.\n\n# Program Rules\n* Do not intentionally harm the experience or usefulness of the service to others, including degradation of services \u0026 denial of service attacks.\n* Do not attempt to view, modify, or damage data belonging to others\n* Do not disclose the reported vulnerability to others until we’ve had reasonable time to address it.\n\n# Bounty Eligibility\n* You must agree and adhere to the Program Rules and Legal terms as stated in this policy.\n* You must be the first to report the issue in order to be eligible for bounty*.\n* You must be available to supply additional information, as needed by our team, to reproduce and triage the issue.\n* Starbucks Partners are not eligible for participation in this program\n\n**Please note that Starbucks has been managing a bug bounty program independent of HackerOne for some time. Reports submitted to our existing program have been submitted outside of the HackerOne platform and, as such, we may not always be able to link to a duplicate report. We appreciate your understanding in this matter as we transition our program to the HackerOne platform.*\n\n# Targets Eligible for Reward\nCurrently, we offer monetary rewards only for the properties listed below.\nSubdomains not specifically listed are not included in the Targets Eligible for Reward.  \nSome unique issue types not related to the domains listed below, such as reports of subdomain takeovers, may also be eligible for reward.\nWe may modify this list over time, so be sure to visit our policy often to review any updates.\n\nIf you have found a vulnerability in a Starbucks site or app not contained within this list, you can still submit, and Starbucks will triage the report.\nThese types of reports will not result in a monetary reward but valid reports that are resolved can improve your reputation score on the HackerOne platform.\n\n* [www.starbucks.com](http://www.starbucks.com)\n* [www.starbucks.ca](http://www.starbucks.ca)\n* [www.starbucks.com.br](http://www.starbucks.com.br)\n* [www.starbucks.fr](http://www.starbucks.com.fr)\n* [www.starbucks.co.uk](http://www.starbucks.com.co.uk)\n* [www.starbucks.de](http://www.starbucks.com.de)\n* [store.starbucks.com](http://store.starbucks.com)\n* [store.starbucks.ca](http://store.starbucks.ca)\n* [store.starbucks.fr](http://store.starbucks.fr)\n* [store.starbucks.co.uk](http://store.starbucks.co.uk)\n* [store.starbucks.de](http://store.starbucks.de)\n* [www.teavana.com](http://www.teavana.com)\n* Starbucks [iOS](https://itunes.apple.com/app/starbucks/id331177714) \u0026 [Android](https://play.google.com/store/apps/details?id=com.starbucks.mobilecard) apps for US, CA, BR, FR, UK, DE\n* [Starbucks app for Windows] (https://www.starbucks.com/coffeehouse/mobile-apps/starbucks-app-for-windows)\n\nMany of our sites share a common platform. Because of this, a vulnerability reported on one domain may exist on another domain if the issue exists in the shared platform itself. For example, an issue reported for starbucks.com may also present in the exact same way on starbucks.ca and the issue will be resolved on both sites with the same fix. We ask that you take the time to try to confirm this first, and include the other vulnerable locations in one report rather than submitting multiple reports. In these cases, we treat the issue as one bug and will close out others as duplicates. Rest assured, we do take the existence of a vulnerability present on multiple sites into consideration during reward time.\n\nPlease consider the following when reporting issues:\n- Many of our eCommerce sites share a common platform including: teavana.com, store.starbucks.*, and some shop.starbucks.* sites. Some bugs may present in only one of the sites, some may present in multiple with the same root cause.\n- Many of our other www.starbucks.* sties share a common platform, including: starbucks.com, starbucks.ca, starbucks.de, starbucks.fr, starbucks.com.br, starbucks.co.uk. Some bugs may present in only one of the sites, some may present in multiple with the same root cause.\n- It speeds up the triage process if you include in your one report other locations where the same bug is present.\n- We do consider the number of locations where the vulnerability exists when awarding.\n- When in doubt, please file a single report and write down your thoughts. If we think you found different vulnerabilities, we’ll be more than happy to let you file another bug so your reputation and signal will get another boost.\n\n# Exclusions\n* Denial of Service attacks\n* Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing) \n* Disclosure of known public files or directories\n* Outdated software / library versions\n* OPTIONS / TRACE HTTP method enabled\n* CSRF on logout\n* CSRF on forms that are available to anonymous users\n* Cookies that lack HTTP Only or Secure settings for non-sensitive data\n* Self-XSS and issues exploitable only through Self-XSS\n* Reports resulting from automated scanning utilities without additional details or a POC demonstrating a specific exploit\n* Attacks requiring physical access to a user's device\n* Attacks dependent upon social engineering of Starbucks employees or vendors.\n* Username enumeration based on login or forgot password pages.\n* Enforcement policies for brute force or account lockout\n* SSL/TLS best practices\n* Clickjacking, without additional details demonstrating a specific exploit\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Use of a known-vulnerable library without a description of an exploit specific to our implementation\n* Password and account recovery policies\n* Presence of autocomplete functionality in form fields\n* Publicly accessible login panels\n* Lack of email address verification during account registration\n* Rate-limiting issues\n* Content spoofing / text injection\n* Missing security headers without additional details or a POC demonstrating a specific exploit \n* Mixed content issues\n* Attacks requiring physical access to device or MiTM\n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on evaluated severity of reported vulnerabilities and risk acceptance.*\n\n#Rewards\nAll bounty amounts will be at the discretion of the Starbucks Bug Bounty team, which will be evaluated for severity, impact, and quality of the report to determine the bounty level. There could be submissions which we accept the risk and will not fix.\n* __Critical__: Bounty min of $4000.00.\nExamples: privilege escalation, remote code execution, SQL injection (depending on impact), unauthorized access to account data.\n\n* __High__: Bounty min of $500.00.\nExamples: Stored XSS against another user, insecure direct object reference to unauthorized data, SQL injection (depending on impact).\n* __Medium__: Bounty min of $250.00\nExamples: XSS (depending on impact), CSRF (depending on impact).\n* __Low__: Bounty min of $100.00\nExamples: XSS (depending on impact), CSRF (depending on impact), Invalidated redirects (depending on impact).\n\n# What to include in your report \nA well written report will allow us to more quickly and accurately triage your submission.\n* A clear description of the issue, including the impact you believe it has to the user, Starbucks, others.\n* Specific reproduction steps including the environment used for testing (browsers, devices, tools, configuration) and any accounts used during testing.\n* Your recommendations to resolve the issue.\n\n# Legal\nStarbucks 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.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-11-30T18:59:35.914Z"},{"id":3542450,"new_policy":"Starbucks believes in a program that fosters collaboration amongst security professionals to help protect our customers’ personal information from malicious activity due to vulnerabilities against our networks, web and mobile applications and set security policies across our organization. We treat the security and safety of our customers’ personal information with the utmost importance.\nFor the protection of our customers, Starbucks does not disclose, discuss or confirm security matters until comprehensively investigating, diagnosing and fixing any known issues.\n\n# Program Rules\n* Do not intentionally harm the experience or usefulness of the service to others, including degradation of services \u0026 denial of service attacks.\n* Do not attempt to view, modify, or damage data belonging to others\n* Do not disclose the reported vulnerability to others until we’ve had reasonable time to address it.\n\n# Bounty Eligibility\n* You must agree and adhere to the Program Rules and Legal terms as stated in this policy.\n* You must be the first to report the issue in order to be eligible for bounty*.\n* You must be available to supply additional information, as needed by our team, to reproduce and triage the issue.\n* Starbucks Partners are not eligible for participation in this program\n\n**Please note that Starbucks has been managing a bug bounty program independent of HackerOne for some time. Reports submitted to our existing program have been submitted outside of the HackerOne platform and, as such, we may not always be able to link to a duplicate report. We appreciate your understanding in this matter as we transition our program to the HackerOne platform.*\n\n# Targets Eligible for Reward\nCurrently, we offer monetary rewards only for the properties listed below.\nSubdomains not specifically listed are not included in the Targets Eligible for Reward.  \nSome unique issue types not related to the domains listed below, such as reports of subdomain takeovers, may also be eligible for reward.\nWe may modify this list over time, so be sure to visit our policy often to review any updates.\n\nIf you have found a vulnerability in a Starbucks site or app not contained within this list, you can still submit, and Starbucks will triage the report.\nThese types of reports will not result in a monetary reward but valid reports that are resolved can improve your reputation score on the HackerOne platform.\n\n* [www.starbucks.com](http://www.starbucks.com)\n* [www.starbucks.ca](http://www.starbucks.ca)\n* [www.starbucks.com.br](http://www.starbucks.com.br)\n* [www.starbucks.fr](http://www.starbucks.com.fr)\n* [www.starbucks.co.uk](http://www.starbucks.com.co.uk)\n* [www.starbucks.de](http://www.starbucks.com.de)\n* [store.starbucks.com](http://store.starbucks.com)\n* [store.starbucks.ca](http://store.starbucks.ca)\n* [store.starbucks.fr](http://store.starbucks.fr)\n* [store.starbucks.co.uk](http://store.starbucks.co.uk)\n* [store.starbucks.de](http://store.starbucks.de)\n* [www.teavana.com](http://www.teavana.com)\n* Starbucks [iOS](https://itunes.apple.com/app/starbucks/id331177714) \u0026 [Android](https://play.google.com/store/apps/details?id=com.starbucks.mobilecard) apps for US, CA, BR, FR, UK, DE\n* [Starbucks app for Windows] (https://www.starbucks.com/coffeehouse/mobile-apps/starbucks-app-for-windows)\n\nMany of our sites share a common platform. Because of this, a vulnerability reported on one domain may exist on another domain if the issue exists in the shared platform itself. For example, an issue reported for starbucks.com may also present in the exact same way on starbucks.ca and the issue will be resolved on both sites with the same fix. We ask that you take the time to try to confirm this first, and include the other vulnerable locations in one report rather than submitting multiple reports. In these cases, we treat the issue as one bug and will close out others as duplicates. Rest assured, we do take the existence of a vulnerability present on multiple sites into consideration during reward time.\n\nPlease consider the following when reporting issues:\n- Many of our eCommerce sites share a common platform including: teavana.com, store.starbucks.*, and some shop.starbucks.* sites. Some bugs may present in only one of the sites, some may present in multiple with the same root cause.\n- Many of our other www.starbucks.* sties share a common platform, including: starbucks.com, starbucks.ca, starbucks.de, starbucks.fr, starbucks.com.br, starbucks.co.uk. Some bugs may present in only one of the sites, some may present in multiple with the same root cause.\n- It speeds up the triage process if you include in your one report other locations where the same bug is present.\n- We do consider the number of locations where the vulnerability exists when awarding.\n- When in doubt, please file a single report and write down your thoughts. If we think you found different vulnerabilities, we’ll be more than happy to let you file another bug so your reputation and signal will get another boost.\n\n# Exclusions\n* Denial of Service attacks\n* Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing) \n* Disclosure of known public files or directories\n* Outdated software / library versions\n* OPTIONS / TRACE HTTP method enabled\n* CSRF on logout\n* CSRF on forms that are available to anonymous users\n* Cookies that lack HTTP Only or Secure settings for non-sensitive data\n* Self-XSS and issues exploitable only through Self-XSS\n* Reports resulting from automated scanning utilities without additional details or a POC demonstrating a specific exploit\n* Attacks requiring physical access to a user's device\n* Attacks dependent upon social engineering of Starbucks employees or vendors.\n* Username enumeration based on login or forgot password pages.\n* Enforcement policies for brute force or account lockout\n* SSL/TLS best practices\n* Clickjacking, without additional details demonstrating a specific exploit\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Use of a known-vulnerable library without a description of an exploit specific to our implementation\n* Password and account recovery policies\n* Presence of autocomplete functionality in form fields\n* Publicly accessible login panels\n* Lack of email address verification during account registration\n* Rate-limiting issues\n* Content spoofing / text injection\n* Missing security headers without additional details or a POC demonstrating a specific exploit \n* Mixed content issues\n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on evaluated severity of reported vulnerabilities and risk acceptance.*\n\n#Rewards\nAll bounty amounts will be at the discretion of the Starbucks Bug Bounty team, which will be evaluated for severity, impact, and quality of the report to determine the bounty level. There could be submissions which we accept the risk and will not fix.\n* __Critical__: Bounty min of $4000.00.\nExamples: privilege escalation, remote code execution, SQL injection (depending on impact), unauthorized access to account data.\n\n* __High__: Bounty min of $500.00.\nExamples: Stored XSS against another user, insecure direct object reference to unauthorized data, SQL injection (depending on impact).\n* __Medium__: Bounty min of $250.00\nExamples: XSS (depending on impact), CSRF (depending on impact).\n* __Low__: Bounty min of $100.00\nExamples: XSS (depending on impact), CSRF (depending on impact), Invalidated redirects (depending on impact).\n\n# What to include in your report \nA well written report will allow us to more quickly and accurately triage your submission.\n* A clear description of the issue, including the impact you believe it has to the user, Starbucks, others.\n* Specific reproduction steps including the environment used for testing (browsers, devices, tools, configuration) and any accounts used during testing.\n* Your recommendations to resolve the issue.\n\n# Legal\nStarbucks 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.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-11-29T16:07:02.613Z"},{"id":3542449,"new_policy":"Starbucks believes in a program that fosters collaboration amongst security professionals to help protect our customers’ personal information from malicious activity due to vulnerabilities against our networks, web and mobile applications and set security policies across our organization. We treat the security and safety of our customers’ personal information with the utmost importance.\nFor the protection of our customers, Starbucks does not disclose, discuss or confirm security matters until comprehensively investigating, diagnosing and fixing any known issues.\n\n# Program Rules\n* Do not intentionally harm the experience or usefulness of the service to others, including degradation of services \u0026 denial of service attacks.\n* Do not attempt to view, modify, or damage data belonging to others\n* Do not disclose the reported vulnerability to others until we’ve had reasonable time to address it.\n\n# Bounty Eligibility\n* You must agree and adhere to the Program Rules and Legal terms as stated in this policy.\n* You must be the first to report the issue in order to be eligible for bounty*.\n* You must be available to supply additional information, as needed by our team, to reproduce and triage the issue.\n* Starbucks Partners are not eligible for participation in this program\n\n**Please note that Starbucks has been managing a bug bounty program independent of HackerOne for some time. Reports submitted to our existing program have been submitted outside of the HackerOne platform and, as such, we may not always be able to link to a duplicate report. We appreciate your understanding in this matter as we transition our program to the HackerOne platform.*\n\n# Targets Eligible for Reward\nCurrently, we offer monetary rewards only for the properties listed below.\nSubdomains not specifically listed are not included in the Targets Eligible for Reward.  \nSome unique issue types not related to the domains listed below, such as reports of subdomain takeovers, may also be eligible for reward.\nWe may modify this list over time, so be sure to visit our policy often to review any updates.\n\nIf you have found a vulnerability in a Starbucks site or app not contained within this list, you can still submit, and Starbucks will triage the report.\nThese types of reports will not result in a monetary reward but valid reports that are resolved can improve your reputation score on the HackerOne platform.\n\n* [www.starbucks.com](http://www.starbucks.com)\n* [www.starbucks.ca](http://www.starbucks.ca)\n* [www.starbucks.com.br](http://www.starbucks.com.br)\n* [www.starbucks.fr](http://www.starbucks.com.fr)\n* [www.starbucks.co.uk](http://www.starbucks.com.co.uk)\n* [www.starbucks.de](http://www.starbucks.com.de)\n* [store.starbucks.com](http://store.starbucks.com)\n* [store.starbucks.ca](http://store.starbucks.ca)\n* [store.starbucks.fr](http://store.starbucks.fr)\n* [store.starbucks.co.uk](http://store.starbucks.co.uk)\n* [store.starbucks.de](http://store.starbucks.de)\n* [www.teavana.com](http://www.teavana.com)\n* Starbucks [iOS](https://itunes.apple.com/app/starbucks/id331177714) \u0026 [Android](https://play.google.com/store/apps/details?id=com.starbucks.mobilecard) apps for US, CA, BR, FR, UK, DE\n* [Starbucks app for Windows] (https://www.starbucks.com/coffeehouse/mobile-apps/starbucks-app-for-windows)\n\nMany of our sites share a common platform. Because of this, a vulnerability reported on one domain may exist on another domain if the issue exists in the shared platform itself. For example, an issue reported for starbucks.com may also present in the exact same way on starbucks.ca and the issue will be resolved on both sites with the same fix. We ask that you take the time to try to confirm this first, and include the other vulnerable locations in one report rather than submitting multiple reports. In these cases, we treat the issue as one bug and will close out others as duplicates. Rest assured, we do take the existence of a vulnerability present on multiple sites into consideration during reward time.\n\nPlease consider the following when reporting issues:\n- Many of our eCommerce sites share a common platform including: teavana.com, store.starbucks.*, and some shop.starbucks.* sites. Some bugs may present in only one of the sites, some may present in multiple with the same root cause.\n- Many of our other www.starbucks.* sties share a common platform, including: starbucks.com, starbucks.ca, starbucks.de, starbucks.fr, starbucks.com.br, starbucks.co.uk. Some bugs may present in only one of the sites, some may present in multiple with the same root cause.\n- It speeds up the triage process if you include in your one report other locations where the same bug is present.\n- We do consider the number of locations where the vulnerability exists when awarding.\n- When in doubt, please file a single report and write down your thoughts. If we think you found different vulnerabilities, we’ll be more than happy to let you file another bug so your reputation and signal will get another boost.\n\n# Exclusions\n* Denial of Service attacks\n* Descriptive error messages or headers (e.g. Stack Traces, application or server errors, banner grabbing) \n* Disclosure of known public files or directories\n* Outdated software / library versions\n* OPTIONS / TRACE HTTP method enabled\n* CSRF on logout\n* CSRF on forms that are available to anonymous users\n* Cookies that lack HTTP Only or Secure settings for non-sensitive data\n* Self-XSS and issues exploitable only through Self-XSS\n* Reports resulting from automated scanning utilities without additional details or a POC demonstrating a specific exploit\n* Attacks requiring physical access to a user's device\n* Attacks dependent upon social engineering of Starbucks employees or vendors.\n* Username enumeration based on login or forgot password pages.\n* Enforcement policies for brute force or account lockout\n* SSL/TLS best practices\n* Clickjacking, without additional details demonstrating a specific exploit\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Use of a known-vulnerable library without a description of an exploit specific to our implementation\n* Password and account recovery policies\n* Presence of autocomplete functionality in form fields\n* Publicly accessible login panels\n* Lack of email address verification during account registration\n* Rate-limiting issues\n* Content spoofing / text injection\n* Missing security headers without additional details or a POC demonstrating a specific exploit \n* Mixed content issues\n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on evaluated severity of reported vulnerabilities and risk acceptance.*\n\n#Rewards\nAll bounty amounts will be at the discretion of the Starbucks Bug Bounty team, which will be evaluated for severity, impact, and quality of the report to determine the bounty level. There could be submissions which we accept the risk and will not fix.\n* __Critical__: Bounty min of $4000.00.\nExamples: privilege escalation, remote code execution, SQL injection (depending on impact), unauthorized access to account data.\n* __High__: Bounty min of $500.00.\nExamples: Stored XSS against another user, insecure direct object reference to unauthorized data, SQL injection (depending on impact).\n* __Medium__: Bounty min of $250.00\nExamples: XSS (depending on impact), CSRF (depending on impact).\n* __Low__: Bounty min of $100.00\nExamples: XSS (depending on impact), CSRF (depending on impact), Invalidated redirects (depending on impact).\n\n# What to include in your report \nA well written report will allow us to more quickly and accurately triage your submission.\n* A clear description of the issue, including the impact you believe it has to the user, Starbucks, others.\n* Specific reproduction steps including the environment used for testing (browsers, devices, tools, configuration) and any accounts used during testing.\n* Your recommendations to resolve the issue.\n\n# Legal\nStarbucks 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.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-11-29T16:04:32.821Z"},{"id":3542448,"new_policy":"Starbucks believes in a program that fosters collaboration amongst security professionals to help protect our customers’ personal information from malicious activity due to vulnerabilities against our networks, web and mobile applications and set security policies across our organization. We treat the security and safety of our customers’ personal information with the utmost importance.\n\nFor the protection of our customers, Starbucks does not disclose, discuss or confirm security matters until comprehensively investigating, diagnosing and fixing any known issues.\n\n\n# Program Rules\n* Existence of, and participation in the private program, must remain confidential.\n* Public disclosure is not permitted.\n* Do not intentionally harm the experience or usefulness of the service to others, including degradation of services \u0026 denial of service attacks.\n* Do not attempt to view, modify, or damage data belonging to others\n\n\n# Bounty Eligibility\n* You must agree and adhere to the Program Rules and Legal terms as stated in this policy.\n* You must be the first to report the issue in order to be eligible for bounty*.\n* You must be available to supply additional information, as needed by our team, to reproduce and triage the issue.\n* Starbucks Partners are not eligible for participation in this program\n\n**Please note that Starbucks has been managing a bug bounty program independent of HackerOne for some time.  Reports submitted to our existing program have been submitted outside of the HackerOne platform and, as such, we may not always be able to link to a duplicate report.  We appreciate your understanding in this matter as we transition our program to the HackerOne platform.*\n\n\n# Targets Eligible for Reward\nCurrently, we offer monetary rewards only for the properties listed below.\nSubdomains not specifically listed are not included in the Targets Eligible for Reward.\n\nWe may modify this list over time, so be sure to visit our policy often to review any updates.\n\nIf you have found a vulnerability in a Starbucks site or app not contained within this list, you can still submit, and Starbucks will triage the report.\nThese types of reports will not result in a monetary reward but valid reports that are resolved can improve your reputation score on the HackerOne platform.\n\n* [www.starbucks.com](http://www.starbucks.com)\n* [www.starbucks.ca](http://www.starbucks.ca)\n* [www.starbucks.com.br](http://www.starbucks.com.br)\n* [www.starbucks.fr](http://www.starbucks.com.fr)\n* [www.starbucks.co.uk](http://www.starbucks.com.co.uk)\n* [www.starbucks.de](http://www.starbucks.com.de)\n* [store.starbucks.com](http://store.starbucks.com)\n* [store.starbucks.ca](http://store.starbucks.ca)\n* [store.starbucks.fr](http://store.starbucks.fr)\n* [store.starbucks.co.uk](http://store.starbucks.co.uk)\n* [store.starbucks.de](http://store.starbucks.de)\n* [www.teavana.com](http://www.teavana.com)\n* Starbucks [iOS](https://itunes.apple.com/app/starbucks/id331177714) \u0026 [Android](https://play.google.com/store/apps/details?id=com.starbucks.mobilecard) apps for US, CA, BR, FR, UK, DE\n* [Starbucks app for Windows] (https://www.starbucks.com/coffeehouse/mobile-apps/starbucks-app-for-windows)\n\nMany of our sites share a common platform. Because of this, a vulnerability reported on one domain may exist on another domain if the issue exists in the shared platform itself. For example, an issue reported for starbucks.com may also present in the exact same way on starbucks.ca and the issue will be resolved on both sites with the same fix. We ask that you take the time to try to confirm this first, and include the other vulnerable locations in one report rather than submitting multiple reports. In these cases, we treat the issue as one bug and will close out others as duplicates. Rest assured, we do take the existence of a vulnerability present on multiple sites into consideration during reward time.\n\nPlease consider the following when reporting issues:\n - Many of our eCommerce sites share a common platform including:  teavana.com, store.starbucks.*, and some shop.starbucks.* sites. Some bugs may present in only one of the sites, some may present in multiple with the same root cause.\n - Many of our other www.starbucks.* sties share a common platform, including:  starbucks.com, starbucks.ca, starbucks.de, starbucks.fr, starbucks.com.br, starbucks.co.uk. Some bugs may present in only one of the sites, some may present in multiple with the same root cause.\n - It speeds up the triage process if you include in your one report other locations where the same bug is present.\n - We do consider the number of locations where the vulnerability exists when awarding.\n - When in doubt, please file a single report and write down your thoughts. If we think you found different vulnerabilities, we’ll be more than happy to let you file another bug so your reputation and signal will get another boost. \n\n\n# Exclusions\n* Denial of Service attacks\n* Descriptive error messages or headers  (e.g. Stack Traces, application or server errors, banner grabbing) \n* Disclosure of known public files or directories\n* Outdated software / library versions\n* OPTIONS / TRACE HTTP method enabled\n* CSRF on logout\n* CSRF on forms that are available to anonymous users\n* Cookies that lack HTTP Only or Secure settings for non-sensitive data\n* Self-XSS and issues exploitable only through Self-XSS\n* Reports resulting from automated scanning utilities without additional details or a POC demonstrating a specific exploit\n* Attacks requiring physical access to a user's device\n* Attacks dependent upon social engineering of Starbucks employees or vendors.\n* Username enumeration based on login or forgot password pages.\n* Enforcement policies for brute force or account lockout\n* SSL/TLS best practices\n* Clickjacking, without additional details demonstrating a specific exploit\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Use of a known-vulnerable library without a description of an exploit specific to our implementation\n* Password and account recovery policies\n* Presence of autocomplete functionality in form fields\n* Publicly accessible login panels\n* Lack of email address verification during account registration\n* Rate-limiting\n\n*Starbucks reserves the right to add to and subtract from the Exclusions list depending on evaluated severity of reported vulnerabilities and risk acceptance.*\n\n\n#Rewards\nAll bounty amounts will be at the discretion of the Starbucks Bug Bounty team, which will be evaluated for severity, impact, and quality of the report to determine the bounty level. There could be submissions which we accept the risk and will not fix.\n\n* __Critical__:  Bounty min of $4000.00.\nExamples: privilege escalation, remote code execution, SQL injection (depending on impact), unauthorized access to account data. \n\n* __High__:  Bounty min of $500.00.\nExamples: Stored XSS against another user, insecure direct object reference to unauthorized data, SQL injection (depending on impact). \n\n* __Medium__:  Bounty min of $250.00\nExamples: XSS (depending on impact), CSRF (depending on impact). \n\n* __Low__:  Bounty min of $100.00\nExamples: XSS (depending on impact), CSRF (depending on impact), Invalidated redirects (depending on impact). \n \n\n# What to include in your report \nA well written report will allow us to more quickly and accurately triage your submission.\n\n* A clear description of the issue, including the impact you believe it has to the user, Starbucks, others.\n* Specific reproduction steps including the environment used for testing (browsers, devices, tools, configuration) and any accounts used during testing.\n* Your recommendations to resolve the issue.\n\n\n# Legal\nStarbucks 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.  \n \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2016-11-29T16:01:42.241Z"}]