[{"id":3770911,"new_policy":"## Slack Technologies, LLC, a Salesforce company\n\nOver _$12M_ in bounties awarded across all our H1 Bug Bounty programs since 2015!\n\nAt Slack, a Salesforce company, Trust is our #1 value and we take the protection of our customers' data very seriously. We encourage responsible reporting and disclosure of any vulnerabilities found in Slack services outlined in our Scope section.\n\nSlack is committed to working with security researchers to verify and address any potential vulnerabilities that are reported to us. Please review these terms before you test and/or report a vulnerability. Slack pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.\n\n##Eligibility for the Bug Bounty Program\n\nWe are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Slack. However, only those researchers that meet the following criteria may be eligible to receive a reward. Some of the requirements to participate in the Bug Bounty Program include:\n\n\n* You must be the first reporter of a vulnerability associated with a participating service (we will also not reward for a known vulnerability which we are actively fixing)\n* You must have personally discovered the vulnerability and you may not report a vulnerability that was discovered by another person (including, and especially, someone who does not qualify to participate in the Bug Bounty Program)\n* You must not be employed by Slack, Salesforce, its subsidiaries, or any related entities, currently or in the last 12 months.\n* You must comply with this Policy when discovering the vulnerability and submitting the vulnerability report\n* Slack or HackerOne can’t be legally prohibited from rewarding you for any reason\n* Non-automated testing is allowed on production Slack infrastructure, preferably using dedicated test teams. Any testing for cross-team vulnerabilities should be conducted using dedicated teams created and owned by the researcher.\n\n##Conduct Guidelines\n\n\nWhile we encourage you to discover and report any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited and will result in disqualification from the Bug Bounty Program. By submitting a report to this program you agree to adhere to these guidelines. \n\n\n* Disclosing any vulnerabilities or suspected vulnerabilities you discover to any other person without explicit Salesforce authorization\n* Disclosing the contents of any submission to this program without explicit Slack authorization\n* Accessing private information of any person stored on a Slack product or service – You must use test accounts\n* Accessing sensitive information (e.g. credentials)\n* Performing actions that may negatively affect Salesforce system performance or its users (e.g. Spam, Phishing, Brute force, Distributed Denial of Service (DDoS))\n* Conducting any kind of physical attack on Slack personnel, property or data centers\n* Social engineering any Slack employee or contractor\n* Conducting vulnerability testing of participating services using anything other than test accounts (e.g. Developer or Trial Edition instances)\n* Exfiltrating data. Please test only the minimum necessary to validate a vulnerability (we can verify if data exfiltration would be possible from a vulnerability, and will reward with the impact in mind)\n* Violating any laws or breaching any agreements in order to discover vulnerabilities\n\nIf you are testing a publicly viewable area of Slack, please remove any test posts or accounts when you are done and refrain from engaging with actual users.\n\n##Disclosure Guidelines\n \nAs of August 15th, 2025, all Disclosure via HackerOne is paused for Slack. Researchers should expect all open and future requests for Mutual Disclosure to be closed until further notice. We will be taking this opportunity to align with our Salesforce bug bounty partners and provide a better experience for our researchers. There are no changes to the requirements for external disclosure outside of HackerOne.\n\nPublic disclosure of any submission to this program outside of the HackerOne platform (e.g. blogs, conference talks, research papers) requires explicit Slack approval regardless of the report status. Any form of public disclosure without explicit approval is considered a violation of our Conduct Guidelines. Please use the request disclosure option and specify that you are requesting to disclose externally. \n\n\n##Our Commitment to Researchers\n\n\nIf you submit a vulnerability report, the Slack security team and associated development organizations will use reasonable efforts to:\n\n\n\n* Respond in a timely manner, acknowledging receipt of your vulnerability report.\n* Investigate and consider your vulnerability report for eligibility under our Bug Bounty Program within 30 days of submission or less.\n* Notify you when the remediation or other action regarding the vulnerability has been implemented. \n\nSlack Products/Services In Scope for HackerOne Security Researchers\n\nThe Bug Bounty Program is limited to Slack products as specified within the *scope* section in HackerOne.\n\n\n\n##Qualifying Vulnerabilities \u0026 Bounties (In Scope)\n\n\nThe decision to grant a reward for a vulnerability report, and the value of a reward (if any), is entirely within Salesforce’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the *impact and severity* of the reported vulnerability. Keep in mind that while a report may identify a valid security concern, it must be a qualifying vulnerability as outlined below for acceptance under this program.\n\n\n* You will qualify for consideration for a reward only if you are the first person to responsibly disclose an unknown vulnerability to us in accordance with these policies. The determination of whether you are the first person is solely within our responsibility. Vulnerabilities must also be relevant, exploitable, and well-documented in the vulnerability report. We are more likely to grant a reward if the vulnerability is specific, fixable and not currently exploited against us or our customers. \n\n##Vulnerability Severity Definitions\n\nThe following vulnerability severity definitions are based on internal Salesforce documentation. These definitions are a work in progress. The goal of adding these definitions to our policy is to: \n\n* Allow more efficient report triage\n* Align directly with internal Salesforce vulnerability ranking definitions\n* Remove ambiguity and subjective assignment of severity\n* Promote fair bounty payments\n* Promote researcher satisfaction\n\nIf you have feedback and/or suggestions to help us make these more clear and useful, please email your ideas to bugbountymanager@salesforce.com\n\n###Critical\n\n* Indicators of a ‘Critical’ severity level include but are not limited to vulnerabilities that:\n    * can affect a customer-facing or Slack production asset, or a non-production environment containing production customer data. Such an impact could be the compromise of the confidentiality, integrity of availability of such an asset or data.\n    * can result in compromise of sensitive systems or customer data without user interaction.\n    * can be exploited externally / via an untrusted network.\n    * can be remotely exploited with minimal knowledge, skill, or complexity.\n    * results in a root-level compromise of servers or infrastructure devices when exploited.\n    * have a CVSS or VPR score of 9.0 or greater.\n* Examples include, but are not limited to:\n    * External Remote Code Execution (RCE): Executing potentially harmful code on a server from outside the network that may result in system compromise and possible data exfiltration, depending on the specific implementation and context.\n    * Critical Data Exposure (Single/Cross-Tenant): Potential unauthorized disclosure of sensitive data that could affect one or multiple customers, with impact varying based on data sensitivity and scope of exposure.\n    * Arbitrary Account Takeover: Potentially gaining significant control of user accounts without proper authorization, where the impact depends on the account type and associated permissions.\n    * Privilege Escalation to Root/Admin: Possible elevation of privileges to higher levels on a system that could lead to varying degrees of control over the affected system or infrastructure.\n    * Exploitation of Publicly Known and Actively Exploited Vulnerabilities: Potentially leveraging known flaws that may be under active attack, where impact varies based on the vulnerability context. The Public Disclosure must be older than 30 days if the risk is Critical.\n    * External Logic Flaws Causing Significant Service Disruption: Possible abuse of application logic accessible externally that might cause service disruptions, with impact varying based on affected business functions and duration.\n\n\n###High\n\n* Indicators of a ‘High’ severity level include but are not limited to vulnerabilities that:\n    * can affect production or customer-facing assets, or non-production environments with sensitive data.\n    * allow unauthorized access or modification of sensitive data or elevated privileges, but require more skill or context than Critical vulnerabilities.\n    * allow local users to gain increased privileges.\n    * result in susceptibility to an external, simply executed, single actor, logic-based attacks resulting in significant performance degradation of one or more critical systems/products.\n    * Can be exploited with moderate technical knowledge or skill, and is likely to result in system compromise or denial of service. Example: A publicly available exploit without evidence of active exploitation, or a proof-of-concept exploit.\n    * Have a CVSS or VPR score between 7.0 and 8.9\n* Examples include, but are not limited to:\n    * Privilege Escalation (Limited Scope): Gaining higher access within the application allowing unauthorized access to sensitive data and functionalities.\n    * External Persistent/Stored Cross-Site Scripting (XSS): Permanently injecting malicious scripts into a website, affecting other users potentially leading to session hijacking or defacement.\n    * External Cross-Site Request Forgery (CSRF) on Sensitive Functions: Forcing a user to perform unwanted actions on a web application leading to unauthorized state changes or data manipulation.\n    * External Exposure of Sensitive Information via Stack Traces: Revealing internal application details in error messages potentially leading to sensitive information leakage.\n    * Internal Use of Weak Cryptography (Practically Exploitable): Using breakable encryption within the internal network potentially leading to confidential data disclosure.\n    * Internal Remote Arbitrary Code Execution (Without Mitigating Circumstances): Executing code on an internal server potentially leading to system compromise or partial service disruption.\n    * Internal Command or SQL Injection (Without Mitigating Circumstances): Injecting malicious commands into an internal system or database allowing unauthorized data access/modification/deletion.\n    * Internal Exposure of Sensitive Information: Unauthorized access to data by internal users potentially leading to data breach or privacy violations.\n    * Internal Use of Default or Weak Credentials: Using easily guessed passwords for internal systems allowing unauthorized system access.\n    * Susceptibility to Publicly Disclosed Vulnerabilities (High Impact): Using software with known, dangerous flaws potentially leading to system compromise or data loss.\n    * External Path Traversal: Accessing restricted files or directories on the server from the outside potentially leading to access to sensitive files or code execution.\n    * Server-Side Request Forgery (SSRF): Forcing the server to make requests to unintended locations potentially leading to access to internal services or data exfiltration.\n    * Unrestricted File Upload (High Risk): Uploading files without proper security checks potentially leading to remote code execution or defacement.\n    * XML External Entity (XXE) Injection: Exploiting vulnerabilities in XML processing potentially leading to confidential data disclosure or remote code execution.\n\n\n###Medium\n\n* Indicators of a ‘Medium’ severity level include but are not limited to vulnerabilities that:\n    * may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances.  Such a difficulty could require significant knowledge or skill to exploit, or there may be controls in place to prevent exploitation.\n    * could have had a critical or high impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.\n    * require significant user interaction or chaining with other bugs to escalate impact.\n    * result in susceptibility to external, simply executed, single actor, logic-based attacks resulting in some measurable performance degradation of one or more critical systems/products.\n    * may involve low-sensitivity data or present a limited attack surface.\n    * have a CVSS or VPR score between 4.0 and 6.9.\n* Examples include, but are not limited to:\n    * External Unintended Internal Information Disclosure: Revealing internal details to external users potentially aiding further attacks.\n    * Internal Network/Application Cross-Site Scripting (XSS): Injecting malicious scripts into an internal web application potentially allowing attackers to hijack user sessions or deface internal applications.\n    * Internal Network/Application Cross-Site Request Forgery (CSRF): Forcing an authenticated internal user to perform unwanted actions potentially leading to unauthorized actions on internal applications.\n    * Internal Use of Weak Cryptography (Practically Exploitable by Sophisticated Actors): Using breakable encryption within the internal network potentially allowing sensitive internal data decryption.\n    * Usage of End-of-Life (EoL) Operating Systems or Software (Internal): Running unsupported software on internal systems increasing susceptibility to known vulnerabilities.\n    * External Facing Content Spoofing: Manipulating content to deceive users potentially leading to phishing or reputational damage.\n    * Cleartext Transmission of Sensitive Internal Data: Sending unencrypted sensitive data within the internal network potentially allowing interception of confidential internal data.\n    * Predictable Session Identifiers (Internal): Using easily guessable session tokens within the internal network potentially allowing attackers to hijack legitimate user sessions.\n    * Denial-of-Service (DoS) via Logic Flaws (Single Actor, Simple Execution, Measurable Performance Degradation): Causing a noticeable slowdown or temporary unavailability of a service with minimal effort.\n    * Path Traversal on Internal Resources: Accessing restricted files or directories within the internal network potentially allowing unauthorized access to sensitive internal configuration files or data.\n    * Missing or Ineffective Rate Limiting on Non-Critical Internal Endpoints: Failing to limit requests to certain internal features potentially leading to resource exhaustion. While researchers should always feel free to report discoveries to our program, we will only accept and pay for valid Medium severity issues related to CVEs 6 months past publish date.\n\n###Low\n\n* Indicators of a ‘Low’ severity level includes but is not limited to vulnerabilities that:\n    * do not expose sensitive data or infrastructure.\n    * represent best practice gaps, low-impact misconfigurations, or non-exploitable flaws.\n    * may be more difficult to exploit but could lead to minimal compromise of the confidentiality, integrity, or availability of resources under unlikely circumstances.\n    * require unlikely circumstances to be able to be exploited, or where a successful exploit would have minimal consequences.\n    * require complex prerequisites or attacker access to internal environments.\n    * results in susceptibility to external, simply executed, single actor, logic-based attacks resulting in minor performance degradation of one or more critical systems/products.\n    * have a CVSS or VPR score less than 4.0.\n* Examples include, but are not limited to:\n    * Cross-Site Scripting (XSS) from an Authenticated Customer Admin: Injecting malicious scripts through an admin account potentially leading to minor data theft or defacement within admin scope.\n    * Exposure of Internal Default Pages (e.g., Apache server-status): Revealing server information through standard configuration pages potentially aiding reconnaissance.\n    * Exposure of Server Configuration Information: Leaking details about the server setup slightly increasing attack surface knowledge.\n    * Use of Weak Cryptography Not Practically Exploitable: Using breakable encryption with mitigating factors presenting negligible real-world risk.\n    * External Cross-Site Request Forgery (CSRF) on Non-Sensitive Functions: Forcing a user to perform unimportant actions on a website potentially leading to unwanted minor actions.\n    * Documentation Bugs Revealing Sensitive but Outdated Information: Documentation inaccuracies that, from a security perspective, misrepresent product behavior, including instances where outdated information could reveal sensitive configurations and cause confusion.\n    * HTTP Public Key Pinning (HPKP) Configuration Errors with Fallback: Misconfiguration of certificate pinning with a working backup indicating a configuration issue.\n    * Verbose Error Messages Revealing Non-Sensitive Information: Detailed error outputs exposing internal application structure or non-critical data. The data exposed must be, at some point, important from a security perspective.\n    * Absence of Rate Limiting on Non-Authentication Related, Low-Impact Features: Lack of request limits on unimportant features potentially leading to minor resource exhaustion.\n    * Information Disclosure Through Non-Standard HTTP Headers: Revealing minor information in HTTP headers slightly increasing knowledge for attackers.\n\n\n##Qualifying Vulnerability Descriptions\n\n\n| Category | Description |\n| --- | --- |\n| Remote Code Execution | CWE-94: AKA \"Arbitrary Code Execution\".  Describes a security bug that allows an attacker to execute arbitrary commands or code on a target machine or in a target process. The exploit PoC may include many other vulnerability types, but ultimately the result is p0wnage of the server(s) and/or environment.  [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Disclosure of Credit Card data | CWE-359:  This is self-explanatory. Any security bug which allows disclosure of credit card information to an unauthorized user or system qualifies as Disclosure of Credit Card Data |\n| SQL Injection | CWE-1027:  SQL injection is a code injection technique in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Unrestricted XXE / File System Access | CWE-611:  External XML Entity Injection (XXE) is a specific type of Server Side Request Forgery(SSRF) which affects an XML processing engine server-side on a target. Specifically, blind XXE is when the results are either error-based or cause 3rd party interaction with services such as HTTP, FTP \u0026 DNS. An XXE attack typically occurs when XML input containing a reference to an external entity is processed by a weakly configured parser. An attacker can leverage an XXE attack to access sensitive data and read local or remote files. In a similar manner to SSRF, an attacker could introduce malicious code through Remote Code Execution (RCE).  [scr: https://blog.zsec.uk/out-of-band-xxe-2/]  [src: https://chris-young.net/2018/04/13/xxe-xml-external-entity/] |\n| Significant Authentication Bypass | CWE-305:  Authentication bypass is a vulnerability that allows an attacker access to credential protected resources without first acquiring valid credentials. Examples of this vulnerability include:* SQL injection during login to bypasses credential authentication* Direct access to resources normally beyond an authentication mechanism, such as a login screen, which do not independently validate the users authenticated session.* Failure to enumerate and enforce the systems' access policy. * A weak authentication system that allows a valid identity to be forged. | \n| Significant Authorization Bypass | CWE-285:  Authorization is the concept of allowing access to resources only to those permitted to use them. Vulnerabilities that bypass authorization checks may allow access to protected resources beyond what was intended by the system. Examples of authorization bypass include Insecure Direct Object Reference and Session Token Alteration. In each of these examples, the system trusts the users' requests because of improper or insecure implementation. |\n| Cross Instance Privilege Escalation | Salesforce is a multi-tenant platform in which \"instances\" are created for each Org. A cross-instance privilege escalation involves some user in instance A having access to data in instance B without proper authorization. |\n| Denial of Service | Susceptibility to an external, simply executed, single actor, logic-based attack resulting in a service outage or significant performance degradation of one or more critical systems/products  |\n| Disclosure of Personal Identifiable Information | CWE-200:  Personally identifiable information, or PII, is any data that could potentially be used to identify a particular person. As it relates to Salesforce, PII Disclosure bugs involve PII data stored within any in-scope platforms, excluding Salesforce Employee data such as Name and Contact information.  [src: https://www.lifelock.com/learn-identity-theft-resources-what-is-personally-identifiable-information.html] |\n| Salesforce Platform Misconfiguration and/or Custom APEX Vulnerabilities (Salesforce Owned/Controlled) | The Salesforce Platform is highly configurable, customizable, and supports custom code in the form of APEX code, Visualforce pages, etc. It is therefore capable of being misconfigured in such a way as to leak information or to otherwise be insecure. This category of vulnerability is specific to Salesforce owned and operated sites, NOT Salesforce customer-owned and operated Salesforce instances. If you identify a configuration vulnerability in a customer site please report it to that company via their Bug Bounty program or their security@\u003csome company dot com\u003e email address. There is no guarantee that the customer will respond to your email or bug submission, and it is out of Salesforce control. Please do not expect Salesforce to handle reports of customer misconfiguration.|\n| Privilege Escalation / Improper Access Control | Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in a software application to gain elevated access to resources that are normally protected from an application or user. The result is that a user with more privileges than intended by the application developer or system administrator can perform unauthorized actions. Note that Privilege Escalation is different from Permission Model Circumvention in that PE involves accessing functionality beyond that assigned to a given role, or somehow adding resource permissions to a given role without authorization, while PMC involves a complete bypass of security controls meant to enforce permissions. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access.  [src: https://en.wikipedia.org/wiki/Privilege_escalation] |\n| Non-XXE SSRF | In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.[src:https://www.owasp.org/index.php/Server_Side_Request_Forgery] |\n| Insecure Direct Object Reference | IDOR occurs when unvalidated user-supplied input is submitted and direct access to the object requested is provided. Vulnerability reports for IDOR are valid when the result is unauthorized information disclosure, modification or destruction of data, or performing a function outside of the limits of the current user. |\n| CRLF injection/HTTP response splitting  | HTTP response splitting occurs when data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. [src: https://www.owasp.org/index.php/HTTP_Response_Splitting] |\n| Circumvention of our Platform’s Permission Model | Permission Model Circumvention involves a complete bypass of security controls meant to enforce permissions. An example of PMC involves an insecurely configured system in which an API gateway fronts for several servers and implements authentication/authorization. The configuration is such that the URI to the backend servers can be identified and they are directly accessible without any additional authentication or authorization checks..While there is an authX model in place, it was trivially circumventable. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access. |\n| Cross-Site Scripting (excluding self-XSS) | CWE-80:  Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. [src:https://en.wikipedia.org/wiki/Cross-site_scripting] |\n| Cross-Site Request Forgery (CSRF) on critical actions | CWE-352:  Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.  [src: https://en.wikipedia.org/wiki/Cross-site_request_forgery] |\n| Insufficiently Protected Credentials / Credential Exposure | CWE-522:  CWE-522: Within the context of the Salesforce/HackerOne Bug Bounty program, credential exposure involves finding, or gaining access to a user or system credentials which are not meant to be public. An example of IPC would be finding a Github or other repo containing configuration files that contain usernames, passwords, API keys, private keys, etc. Another example is an exposure of a single user's credentials on the querystring, in cookies, or in other HTTP headers. |\n| Insecure/Open Redirect | CWE-601:  An HTTP parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. |\n| DNS Hijacking / Subdomain Takeover | DNS hijacking or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries.The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.  [src: https://en.wikipedia.org/wiki/DNS_hijacking] [src: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers] |\n| Configuration/Stats//Log File Exposure | CWE-532 Information Exposure Through Log Files. CWE-200: Information Exposure. Any instance in which log files or server/application configuration files are accessible when they are not meant to be. |\n| Documentation Bug | Any instance in which, from a strictly security-based perspective, the published documentation is incorrect with regard to the behavior of the product. | \n\n\n##Non-Qualifying Vulnerabilities (Out of Scope)\n\nThe following types of issues are *specifically excluded* from our Bug Bounty Program:\n\n* Attacks requiring physical access to a user's unlocked device\n* Reports of spam, phishing or security best practices\n* Clickjacking and issues only exploitable through clickjacking\n* CSRF-able actions that do not require authentication (or a session) to exploit or CSRF issues which have no security impact to Slack.\n* HTML and Link injections\n* Non-Critical reports that are theoretical and do not demonstrate a working proof of concept\n* Nebula-related attacks requiring code changes on the victim (server) side\n* Attacks that require modifying the Nebula config file to take malicious actions\n* Nebula-related attacks that involve modifying the SSH server to take malicious action\n* Nebula-related DoS issues that require authentication or misconfigured firewall rules\n* Reports of exposed customer tokens, webhooks, etc. via Wayback Machine or other third-party sites\n* Issues related to \"Editable Github Wiki Pages\"\n* Issues related to Salesforce *Partner* User Credential Disclosure in public code repositories such as GitHub. *Please note that this type of activity is explicitly excluded by the Conduct Guidelines in this policy.*\n* TOCTOU bugs involving platform permission changes. For example; User A has an active session, Admin reduces or increases permissions for User A, User A permissions do not change until User A logs out and back in. This is currently WAD on Salesforce platforms.\n* Invalid links from any Slack site to any social media site in which a claim of \"account takeover\" or \"possible phishing attacks\" are the basis for the report.\n* Bugs in content/services that are not owned/operated by Slack (Salesforce)\n* Vulnerabilities affecting users of outdated or unsupported browsers or platforms\n* Vulnerabilities that have already been addressed in a product update regardless of whether the update has been applied to the publicly available research machines\n* Subdomain takeovers for out of scope domains\n* Self-XSS or XSS bugs requiring an unlikely amount of user interaction\n- XSS under \\.sitepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.livepreview.(na\\/gus).force.com (http://force.com/)\n- Descriptive error messages (e.g. Stack Traces, application or server errors)\n- HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n- Fingerprinting / banner disclosure on common/public services.\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Scripting or other automation and brute-forcing of intended functionality\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n- Lack of Secure and HTTPOnly cookie flags\n- Content spoofing (text injection) or IDN homograph attacks\n- Tabnabbing \n- Email configuration issues (SPF, DKIM, DMARC)\n- Weak Captcha / Captcha Bypass\n- Forced Login / Logout CSRF\n- Account lockout, Login or Forgot Password page brute force\n- Password complexity or account recovery policies\n- Username / email enumeration (brute force)\n- HTTPS Mixed Content\n- Missing HTTP security headers, specifically: Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy.\n- OPTIONS HTTP method enabled\n- Known SSL issues (e.g. attacks such as BEAST, BREACH, POODLE, TLS Renegotiation)\n- SSL Forward Secrecy or HSTS not enabled\n- Weak SSL/TLS Cipher Suites\n- CSV Excel Formula injection\n- Issues related to networking protocols or industry standards not controlled by Salesforce\n- Sending vulnerability reports using automated tools without validation\n- Use of a known-vulnerable library without evidence of exploitability\n- Reflected XSS involving Adobe Flash files (.swf)\n\n*If you are unsure whether a bug or issue that you discover in a participating service is a non-qualifying vulnerability, please email us at \u003cbugbountymanager@salesforce.com\u003e*\n\n\n_Intellectual Property_\n\n\nParticipating in the Bug Bounty Program does not grant to you or any other third party any rights to any Slack or Salesforce intellectual property, product or service. All rights not otherwise granted herein are expressly reserved. Whether or not we grant you a reward, you hereby assign to Salesforce all right, title and interest (including all intellectual property rights), in the contents of all vulnerability reports that you submit to Salesforce. \n\nBy participating in the Bug Bounty Program, you represent that you have the right to assign all such right, title and interest to us and that your participation in the Bug Bounty Program and assignment of such right, title and interest will not breach any agreement you may have with a third party (e.g. your employer).\n\n\n_Other Terms and Conditions_\n\n\nSalesforce pledges not to pursue a civil action or initiate a complaint to law enforcement against researchers for security research and vulnerability disclosure activities conducted in accordance with this Policy. We consider security research and vulnerability disclosure activities conducted in accordance with this Policy “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA and applicable anti-hacking laws such as Cal. Penal Code 502(c). We waive any DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy.\n\nBy participating in the Bug Bounty Program, you agree to be bound by these rules. These policies will apply to you in addition to, and will not replace, any other terms and conditions that are imposed by HackerOne.\n\n- Your participation in the Bug Bounty Program does not create any kind of employment relationship or partnership between you and Salesforce. You must not hold yourself out as a Salesforce employee or as someone in any way affiliated with Salesforce.\n- You must comply with all applicable laws in connection with your participation in this program. \n- You are responsible for any applicable taxes associated with any reward you receive. \n- Vulnerability reports received prior to the Bug Bounty Program launch are not eligible for rewards and may not be re-submitted for a reward.\n- You will not use any of our trademarks, service marks and logos.\n- We may modify this Policy at any time by posting an updated version of this document.\n- We may terminate this Bug Bounty Program at any time without notice. \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":"2026-03-11T20:35:47.379Z"},{"id":3770887,"new_policy":"## Slack Technologies, LLC, a Salesforce company\n\nOver _$12M_ in bounties awarded across all our H1 Bug Bounty programs since 2015!\n\nAt Slack, a Salesforce company, Trust is our #1 value and we take the protection of our customers' data very seriously. We encourage responsible reporting and disclosure of any vulnerabilities found in Slack services outlined in our Scope section.\n\nSlack is committed to working with security researchers to verify and address any potential vulnerabilities that are reported to us. Please review these terms before you test and/or report a vulnerability. Slack pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.\n\n##Eligibility for the Bug Bounty Program\n\nWe are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Slack. However, only those researchers that meet the following criteria may be eligible to receive a reward. Some of the requirements to participate in the Bug Bounty Program include:\n\n\n* You must be the first reporter of a vulnerability associated with a participating service (we will also not reward for a known vulnerability which we are actively fixing)\n* You must have personally discovered the vulnerability and you may not report a vulnerability that was discovered by another person (including, and especially, someone who does not qualify to participate in the Bug Bounty Program)\n* You must not be employed by Slack, Salesforce, its subsidiaries, or any related entities, currently or in the last 12 months.\n* You must comply with this Policy when discovering the vulnerability and submitting the vulnerability report\n* Slack or HackerOne can’t be legally prohibited from rewarding you for any reason\n* Non-automated testing is allowed on production Slack infrastructure, preferably using dedicated test teams. Any testing for cross-team vulnerabilities should be conducted using dedicated teams created and owned by the researcher.\n\n##Conduct Guidelines\n\n\nWhile we encourage you to discover and report any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited and will result in disqualification from the Bug Bounty Program. By submitting a report to this program you agree to adhere to these guidelines. \n\n\n* Disclosing any vulnerabilities or suspected vulnerabilities you discover to any other person without explicit Salesforce authorization\n* Disclosing the contents of any submission to this program without explicit Slack authorization\n* Accessing private information of any person stored on a Slack product or service – You must use test accounts\n* Accessing sensitive information (e.g. credentials)\n* Performing actions that may negatively affect Salesforce system performance or its users (e.g. Spam, Phishing, Brute force, Distributed Denial of Service (DDoS))\n* Conducting any kind of physical attack on Slack personnel, property or data centers\n* Social engineering any Slack employee or contractor\n* Conducting vulnerability testing of participating services using anything other than test accounts (e.g. Developer or Trial Edition instances)\n* Exfiltrating data. Please test only the minimum necessary to validate a vulnerability (we can verify if data exfiltration would be possible from a vulnerability, and will reward with the impact in mind)\n* Violating any laws or breaching any agreements in order to discover vulnerabilities\n\nIf you are testing a publicly viewable area of Slack, please remove any test posts or accounts when you are done and refrain from engaging with actual users.\n\n##Disclosure Guidelines\n \nAs of August 15th, 2025, all Disclosure via HackerOne is paused for Slack. Researchers should expect all open and future requests for Mutual Disclosure to be closed until further notice. We will be taking this opportunity to align with our Salesforce bug bounty partners and provide a better experience for our researchers. There are no changes to the requirements for external disclosure outside of HackerOne.\n\nPublic disclosure of any submission to this program outside of the HackerOne platform (e.g. blogs, conference talks, research papers) requires explicit Slack approval regardless of the report status. Any form of public disclosure without explicit approval is considered a violation of our Conduct Guidelines. Please use the request disclosure option and specify that you are requesting to disclose externally. \n\n\n##Our Commitment to Researchers\n\n\nIf you submit a vulnerability report, the Slack security team and associated development organizations will use reasonable efforts to:\n\n\n\n* Respond in a timely manner, acknowledging receipt of your vulnerability report.\n* Investigate and consider your vulnerability report for eligibility under our Bug Bounty Program within 30 days of submission or less.\n* Notify you when the remediation or other action regarding the vulnerability has been implemented. \n\nSlack Products/Services In Scope for HackerOne Security Researchers\n\nThe Bug Bounty Program is limited to Slack products as specified within the *scope* section in HackerOne.\n\n\n\n##Qualifying Vulnerabilities \u0026 Bounties (In Scope)\n\n\nThe decision to grant a reward for a vulnerability report, and the value of a reward (if any), is entirely within Salesforce’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the *impact and severity* of the reported vulnerability. Keep in mind that while a report may identify a valid security concern, it must be a qualifying vulnerability as outlined below for acceptance under this program.\n\n\n* You will qualify for consideration for a reward only if you are the first person to responsibly disclose an unknown vulnerability to us in accordance with these policies. The determination of whether you are the first person is solely within our responsibility. Vulnerabilities must also be relevant, exploitable, and well-documented in the vulnerability report. We are more likely to grant a reward if the vulnerability is specific, fixable and not currently exploited against us or our customers. \n\n##Vulnerability Severity Definitions\n\nThe following vulnerability severity definitions are based on internal Salesforce documentation. These definitions are a work in progress. The goal of adding these definitions to our policy is to: \n\n* Allow more efficient report triage\n* Align directly with internal Salesforce vulnerability ranking definitions\n* Remove ambiguity and subjective assignment of severity\n* Promote fair bounty payments\n* Promote researcher satisfaction\n\nIf you have feedback and/or suggestions to help us make these more clear and useful, please email your ideas to bugbountymanager@salesforce.com\n\n###Critical\n\n* Indicators of a ‘Critical’ severity level include but are not limited to vulnerabilities that:\n    * can affect a customer-facing or Slack production asset, or a non-production environment containing production customer data. Such an impact could be the compromise of the confidentiality, integrity of availability of such an asset or data.\n    * can result in compromise of sensitive systems or customer data without user interaction.\n    * can be exploited externally / via an untrusted network.\n    * can be remotely exploited with minimal knowledge, skill, or complexity.\n    * results in a root-level compromise of servers or infrastructure devices when exploited.\n    * have a CVSS or VPR score of 9.0 or greater.\n* Examples include, but are not limited to:\n    * External Remote Code Execution (RCE): Executing potentially harmful code on a server from outside the network that may result in system compromise and possible data exfiltration, depending on the specific implementation and context.\n    * Critical Data Exposure (Single/Cross-Tenant): Potential unauthorized disclosure of sensitive data that could affect one or multiple customers, with impact varying based on data sensitivity and scope of exposure.\n    * Arbitrary Account Takeover: Potentially gaining significant control of user accounts without proper authorization, where the impact depends on the account type and associated permissions.\n    * Privilege Escalation to Root/Admin: Possible elevation of privileges to higher levels on a system that could lead to varying degrees of control over the affected system or infrastructure.\n    * Exploitation of Publicly Known and Actively Exploited Vulnerabilities: Potentially leveraging known flaws that may be under active attack, where impact varies based on the vulnerability context. The Public Disclosure must be older than 30 days if the risk is Critical.\n    * External Logic Flaws Causing Significant Service Disruption: Possible abuse of application logic accessible externally that might cause service disruptions, with impact varying based on affected business functions and duration.\n\n\n###High\n\n* Indicators of a ‘High’ severity level include but are not limited to vulnerabilities that:\n    * can affect production or customer-facing assets, or non-production environments with sensitive data.\n    * allow unauthorized access or modification of sensitive data or elevated privileges, but require more skill or context than Critical vulnerabilities.\n    * allow local users to gain increased privileges.\n    * result in susceptibility to an external, simply executed, single actor, logic-based attacks resulting in significant performance degradation of one or more critical systems/products.\n    * Can be exploited with moderate technical knowledge or skill, and is likely to result in system compromise or denial of service. Example: A publicly available exploit without evidence of active exploitation, or a proof-of-concept exploit.\n    * Have a CVSS or VPR score between 7.0 and 8.9\n* Examples include, but are not limited to:\n    * Privilege Escalation (Limited Scope): Gaining higher access within the application allowing unauthorized access to sensitive data and functionalities.\n    * External Persistent/Stored Cross-Site Scripting (XSS): Permanently injecting malicious scripts into a website, affecting other users potentially leading to session hijacking or defacement.\n    * External Cross-Site Request Forgery (CSRF) on Sensitive Functions: Forcing a user to perform unwanted actions on a web application leading to unauthorized state changes or data manipulation.\n    * External Exposure of Sensitive Information via Stack Traces: Revealing internal application details in error messages potentially leading to sensitive information leakage.\n    * Internal Use of Weak Cryptography (Practically Exploitable): Using breakable encryption within the internal network potentially leading to confidential data disclosure.\n    * Internal Remote Arbitrary Code Execution (Without Mitigating Circumstances): Executing code on an internal server potentially leading to system compromise or partial service disruption.\n    * Internal Command or SQL Injection (Without Mitigating Circumstances): Injecting malicious commands into an internal system or database allowing unauthorized data access/modification/deletion.\n    * Internal Exposure of Sensitive Information: Unauthorized access to data by internal users potentially leading to data breach or privacy violations.\n    * Internal Use of Default or Weak Credentials: Using easily guessed passwords for internal systems allowing unauthorized system access.\n    * Susceptibility to Publicly Disclosed Vulnerabilities (High Impact): Using software with known, dangerous flaws potentially leading to system compromise or data loss.\n    * External Path Traversal: Accessing restricted files or directories on the server from the outside potentially leading to access to sensitive files or code execution.\n    * Server-Side Request Forgery (SSRF): Forcing the server to make requests to unintended locations potentially leading to access to internal services or data exfiltration.\n    * Unrestricted File Upload (High Risk): Uploading files without proper security checks potentially leading to remote code execution or defacement.\n    * XML External Entity (XXE) Injection: Exploiting vulnerabilities in XML processing potentially leading to confidential data disclosure or remote code execution.\n\n\n###Medium\n\n* Indicators of a ‘Medium’ severity level include but are not limited to vulnerabilities that:\n    * may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances.  Such a difficulty could require significant knowledge or skill to exploit, or there may be controls in place to prevent exploitation.\n    * could have had a critical or high impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.\n    * require significant user interaction or chaining with other bugs to escalate impact.\n    * result in susceptibility to external, simply executed, single actor, logic-based attacks resulting in some measurable performance degradation of one or more critical systems/products.\n    * may involve low-sensitivity data or present a limited attack surface.\n    * have a CVSS or VPR score between 4.0 and 6.9.\n* Examples include, but are not limited to:\n    * External Unintended Internal Information Disclosure: Revealing internal details to external users potentially aiding further attacks.\n    * Internal Network/Application Cross-Site Scripting (XSS): Injecting malicious scripts into an internal web application potentially allowing attackers to hijack user sessions or deface internal applications.\n    * Internal Network/Application Cross-Site Request Forgery (CSRF): Forcing an authenticated internal user to perform unwanted actions potentially leading to unauthorized actions on internal applications.\n    * Internal Use of Weak Cryptography (Practically Exploitable by Sophisticated Actors): Using breakable encryption within the internal network potentially allowing sensitive internal data decryption.\n    * Usage of End-of-Life (EoL) Operating Systems or Software (Internal): Running unsupported software on internal systems increasing susceptibility to known vulnerabilities.\n    * External Facing Content Spoofing: Manipulating content to deceive users potentially leading to phishing or reputational damage.\n    * Cleartext Transmission of Sensitive Internal Data: Sending unencrypted sensitive data within the internal network potentially allowing interception of confidential internal data.\n    * Predictable Session Identifiers (Internal): Using easily guessable session tokens within the internal network potentially allowing attackers to hijack legitimate user sessions.\n    * Denial-of-Service (DoS) via Logic Flaws (Single Actor, Simple Execution, Measurable Performance Degradation): Causing a noticeable slowdown or temporary unavailability of a service with minimal effort.\n    * Path Traversal on Internal Resources: Accessing restricted files or directories within the internal network potentially allowing unauthorized access to sensitive internal configuration files or data.\n    * Missing or Ineffective Rate Limiting on Non-Critical Internal Endpoints: Failing to limit requests to certain internal features potentially leading to resource exhaustion. While researchers should always feel free to report discoveries to our program, we will only accept and pay for valid Medium severity issues related to CVEs 6 months past publish date.\n\n###Low\n\n* Indicators of a ‘Low’ severity level includes but is not limited to vulnerabilities that:\n    * do not expose sensitive data or infrastructure.\n    * represent best practice gaps, low-impact misconfigurations, or non-exploitable flaws.\n    * may be more difficult to exploit but could lead to minimal compromise of the confidentiality, integrity, or availability of resources under unlikely circumstances.\n    * require unlikely circumstances to be able to be exploited, or where a successful exploit would have minimal consequences.\n    * require complex prerequisites or attacker access to internal environments.\n    * results in susceptibility to external, simply executed, single actor, logic-based attacks resulting in minor performance degradation of one or more critical systems/products.\n    * have a CVSS or VPR score less than 4.0.\n* Examples include, but are not limited to:\n    * Cross-Site Scripting (XSS) from an Authenticated Customer Admin: Injecting malicious scripts through an admin account potentially leading to minor data theft or defacement within admin scope.\n    * Exposure of Internal Default Pages (e.g., Apache server-status): Revealing server information through standard configuration pages potentially aiding reconnaissance.\n    * Exposure of Server Configuration Information: Leaking details about the server setup slightly increasing attack surface knowledge.\n    * Use of Weak Cryptography Not Practically Exploitable: Using breakable encryption with mitigating factors presenting negligible real-world risk.\n    * External Cross-Site Request Forgery (CSRF) on Non-Sensitive Functions: Forcing a user to perform unimportant actions on a website potentially leading to unwanted minor actions.\n    * Documentation Bugs Revealing Sensitive but Outdated Information: Documentation inaccuracies that, from a security perspective, misrepresent product behavior, including instances where outdated information could reveal sensitive configurations and cause confusion.\n    * HTTP Public Key Pinning (HPKP) Configuration Errors with Fallback: Misconfiguration of certificate pinning with a working backup indicating a configuration issue.\n    * Verbose Error Messages Revealing Non-Sensitive Information: Detailed error outputs exposing internal application structure or non-critical data. The data exposed must be, at some point, important from a security perspective.\n    * Absence of Rate Limiting on Non-Authentication Related, Low-Impact Features: Lack of request limits on unimportant features potentially leading to minor resource exhaustion.\n    * Information Disclosure Through Non-Standard HTTP Headers: Revealing minor information in HTTP headers slightly increasing knowledge for attackers.\n\n\n##Qualifying Vulnerability Descriptions\n\n\n| Category | Description |\n| --- | --- |\n| Remote Code Execution | CWE-94: AKA \"Arbitrary Code Execution\".  Describes a security bug that allows an attacker to execute arbitrary commands or code on a target machine or in a target process. The exploit PoC may include many other vulnerability types, but ultimately the result is p0wnage of the server(s) and/or environment.  [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Disclosure of Credit Card data | CWE-359:  This is self-explanatory. Any security bug which allows disclosure of credit card information to an unauthorized user or system qualifies as Disclosure of Credit Card Data |\n| SQL Injection | CWE-1027:  SQL injection is a code injection technique in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Unrestricted XXE / File System Access | CWE-611:  External XML Entity Injection (XXE) is a specific type of Server Side Request Forgery(SSRF) which affects an XML processing engine server-side on a target. Specifically, blind XXE is when the results are either error-based or cause 3rd party interaction with services such as HTTP, FTP \u0026 DNS. An XXE attack typically occurs when XML input containing a reference to an external entity is processed by a weakly configured parser. An attacker can leverage an XXE attack to access sensitive data and read local or remote files. In a similar manner to SSRF, an attacker could introduce malicious code through Remote Code Execution (RCE).  [scr: https://blog.zsec.uk/out-of-band-xxe-2/]  [src: https://chris-young.net/2018/04/13/xxe-xml-external-entity/] |\n| Significant Authentication Bypass | CWE-305:  Authentication bypass is a vulnerability that allows an attacker access to credential protected resources without first acquiring valid credentials. Examples of this vulnerability include:* SQL injection during login to bypasses credential authentication* Direct access to resources normally beyond an authentication mechanism, such as a login screen, which do not independently validate the users authenticated session.* Failure to enumerate and enforce the systems' access policy. * A weak authentication system that allows a valid identity to be forged. | \n| Significant Authorization Bypass | CWE-285:  Authorization is the concept of allowing access to resources only to those permitted to use them. Vulnerabilities that bypass authorization checks may allow access to protected resources beyond what was intended by the system. Examples of authorization bypass include Insecure Direct Object Reference and Session Token Alteration. In each of these examples, the system trusts the users' requests because of improper or insecure implementation. |\n| Cross Instance Privilege Escalation | Salesforce is a multi-tenant platform in which \"instances\" are created for each Org. A cross-instance privilege escalation involves some user in instance A having access to data in instance B without proper authorization. |\n| Denial of Service | Susceptibility to an external, simply executed, single actor, logic-based attack resulting in a service outage or significant performance degradation of one or more critical systems/products  |\n| Disclosure of Personal Identifiable Information | CWE-200:  Personally identifiable information, or PII, is any data that could potentially be used to identify a particular person. As it relates to Salesforce, PII Disclosure bugs involve PII data stored within any in-scope platforms, excluding Salesforce Employee data such as Name and Contact information.  [src: https://www.lifelock.com/learn-identity-theft-resources-what-is-personally-identifiable-information.html] |\n| Salesforce Platform Misconfiguration and/or Custom APEX Vulnerabilities (Salesforce Owned/Controlled) | The Salesforce Platform is highly configurable, customizable, and supports custom code in the form of APEX code, Visualforce pages, etc. It is therefore capable of being misconfigured in such a way as to leak information or to otherwise be insecure. This category of vulnerability is specific to Salesforce owned and operated sites, NOT Salesforce customer-owned and operated Salesforce instances. If you identify a configuration vulnerability in a customer site please report it to that company via their Bug Bounty program or their security@\u003csome company dot com\u003e email address. There is no guarantee that the customer will respond to your email or bug submission, and it is out of Salesforce control. Please do not expect Salesforce to handle reports of customer misconfiguration.|\n| Privilege Escalation / Improper Access Control | Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in a software application to gain elevated access to resources that are normally protected from an application or user. The result is that a user with more privileges than intended by the application developer or system administrator can perform unauthorized actions. Note that Privilege Escalation is different from Permission Model Circumvention in that PE involves accessing functionality beyond that assigned to a given role, or somehow adding resource permissions to a given role without authorization, while PMC involves a complete bypass of security controls meant to enforce permissions. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access.  [src: https://en.wikipedia.org/wiki/Privilege_escalation] |\n| Non-XXE SSRF | In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.[src:https://www.owasp.org/index.php/Server_Side_Request_Forgery] |\n| Insecure Direct Object Reference | IDOR occurs when unvalidated user-supplied input is submitted and direct access to the object requested is provided. Vulnerability reports for IDOR are valid when the result is unauthorized information disclosure, modification or destruction of data, or performing a function outside of the limits of the current user. |\n| CRLF injection/HTTP response splitting  | HTTP response splitting occurs when data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. [src: https://www.owasp.org/index.php/HTTP_Response_Splitting] |\n| Circumvention of our Platform’s Permission Model | Permission Model Circumvention involves a complete bypass of security controls meant to enforce permissions. An example of PMC involves an insecurely configured system in which an API gateway fronts for several servers and implements authentication/authorization. The configuration is such that the URI to the backend servers can be identified and they are directly accessible without any additional authentication or authorization checks..While there is an authX model in place, it was trivially circumventable. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access. |\n| Cross-Site Scripting (excluding self-XSS) | CWE-80:  Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. [src:https://en.wikipedia.org/wiki/Cross-site_scripting] |\n| Cross-Site Request Forgery (CSRF) on critical actions | CWE-352:  Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.  [src: https://en.wikipedia.org/wiki/Cross-site_request_forgery] |\n| Insufficiently Protected Credentials / Credential Exposure | CWE-522:  CWE-522: Within the context of the Salesforce/HackerOne Bug Bounty program, credential exposure involves finding, or gaining access to a user or system credentials which are not meant to be public. An example of IPC would be finding a Github or other repo containing configuration files that contain usernames, passwords, API keys, private keys, etc. Another example is an exposure of a single user's credentials on the querystring, in cookies, or in other HTTP headers. |\n| Insecure/Open Redirect | CWE-601:  An HTTP parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. |\n| DNS Hijacking / Subdomain Takeover | DNS hijacking or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries.The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.  [src: https://en.wikipedia.org/wiki/DNS_hijacking] [src: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers] |\n| Configuration/Stats//Log File Exposure | CWE-532 Information Exposure Through Log Files. CWE-200: Information Exposure. Any instance in which log files or server/application configuration files are accessible when they are not meant to be. |\n| Documentation Bug | Any instance in which, from a strictly security-based perspective, the published documentation is incorrect with regard to the behavior of the product. | \n\n\n##Non-Qualifying Vulnerabilities (Out of Scope)\n\n\nThe following types of issues are *specifically excluded* from our Bug Bounty Program:\n\n##Non-Qualifying Vulnerabilities (Out of Scope)\n\n\nThe following types of issues are *specifically excluded* from our Bug Bounty Program:\n\n* Attacks requiring physical access to a user's unlocked device\n* Reports of spam, phishing or security best practices\n* Clickjacking and issues only exploitable through clickjacking\n* CSRF-able actions that do not require authentication (or a session) to exploit or CSRF issues which have no security impact to Slack.\n* HTML and Link injections\n* Non-Critical reports that are theoretical and cannot demonstrate a working proof of concept\n* Nebula-related attacks requiring code changes on the victim (server) side\n* Attacks that require modifying the Nebula config file to take malicious actions\n* Nebula-related attacks that involve modifying the SSH server to take malicious action\n* Nebula-related DoS issues that require authentication or misconfigured firewall rules\n* Issues related to \"Editable Github Wiki Pages\"\n* Issues related to Salesforce *Partner* User Credential Disclosure in public code repositories such as GitHub. *Please note that this type of activity is explicitly excluded by the Conduct Guidelines in this policy.*\n* TOCTOU bugs involving platform permission changes. For example; User A has an active session, Admin reduces or increases permissions for User A, User A permissions do not change until User A logs out and back in. This is currently WAD on Salesforce platforms.\n* Invalid links from any Slack site to any social media site in which a claim of \"account takeover\" or \"possible phishing attacks\" are the basis for the report.\n* Bugs in content/services that are not owned/operated by Slack (Salesforce)\n* Vulnerabilities affecting users of outdated or unsupported browsers or platforms\n* Vulnerabilities that have already been addressed in a product update regardless of whether the update has been applied to the publicly available research machines\n* Subdomain takeovers for out of scope domains\n* Self-XSS or XSS bugs requiring an unlikely amount of user interaction\n- XSS under \\.sitepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.livepreview.(na\\/gus).force.com (http://force.com/)\n- Descriptive error messages (e.g. Stack Traces, application or server errors)\n- HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n- Fingerprinting / banner disclosure on common/public services.\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Scripting or other automation and brute-forcing of intended functionality\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n- Lack of Secure and HTTPOnly cookie flags\n- Content spoofing (text injection) or IDN homograph attacks\n- Tabnabbing \n- Email configuration issues (SPF, DKIM, DMARC)\n- Weak Captcha / Captcha Bypass\n- Forced Login / Logout CSRF\n- Account lockout, Login or Forgot Password page brute force\n- Password complexity or account recovery policies\n- Username / email enumeration (brute force)\n- HTTPS Mixed Content\n- Missing HTTP security headers, specifically: Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy.\n- OPTIONS HTTP method enabled\n- Known SSL issues (e.g. attacks such as BEAST, BREACH, POODLE, TLS Renegotiation)\n- SSL Forward Secrecy or HSTS not enabled\n- Weak SSL/TLS Cipher Suites\n- CSV Excel Formula injection\n- Issues related to networking protocols or industry standards not controlled by Salesforce\n- Sending vulnerability reports using automated tools without validation\n- Use of a known-vulnerable library without evidence of exploitability\n- Reflected XSS involving Adobe Flash files (.swf)\n\n*If you are unsure whether a bug or issue that you discover in a participating service is a non-qualifying vulnerability, please email us at \u003cbugbountymanager@salesforce.com\u003e*\n\n\n_Intellectual Property_\n\n\nParticipating in the Bug Bounty Program does not grant to you or any other third party any rights to any Slack or Salesforce intellectual property, product or service. All rights not otherwise granted herein are expressly reserved. Whether or not we grant you a reward, you hereby assign to Salesforce all right, title and interest (including all intellectual property rights), in the contents of all vulnerability reports that you submit to Salesforce. \n\nBy participating in the Bug Bounty Program, you represent that you have the right to assign all such right, title and interest to us and that your participation in the Bug Bounty Program and assignment of such right, title and interest will not breach any agreement you may have with a third party (e.g. your employer).\n\n\n_Other Terms and Conditions_\n\n\nSalesforce pledges not to pursue a civil action or initiate a complaint to law enforcement against researchers for security research and vulnerability disclosure activities conducted in accordance with this Policy. We consider security research and vulnerability disclosure activities conducted in accordance with this Policy “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA and applicable anti-hacking laws such as Cal. Penal Code 502(c). We waive any DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy.\n\nBy participating in the Bug Bounty Program, you agree to be bound by these rules. These policies will apply to you in addition to, and will not replace, any other terms and conditions that are imposed by HackerOne.\n\n- Your participation in the Bug Bounty Program does not create any kind of employment relationship or partnership between you and Salesforce. You must not hold yourself out as a Salesforce employee or as someone in any way affiliated with Salesforce.\n- You must comply with all applicable laws in connection with your participation in this program. \n- You are responsible for any applicable taxes associated with any reward you receive. \n- Vulnerability reports received prior to the Bug Bounty Program launch are not eligible for rewards and may not be re-submitted for a reward.\n- You will not use any of our trademarks, service marks and logos.\n- We may modify this Policy at any time by posting an updated version of this document.\n- We may terminate this Bug Bounty Program at any time without notice. \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":"2026-03-11T16:04:05.427Z"},{"id":3761849,"new_policy":"## Slack Technologies, LLC, a Salesforce company\n\nOver _$12M_ in bounties awarded across all our H1 Bug Bounty programs since 2015!\n\nAt Slack, a Salesforce company, Trust is our #1 value and we take the protection of our customers' data very seriously. We encourage responsible reporting and disclosure of any vulnerabilities found in Slack services outlined in our Scope section.\n\nSlack is committed to working with security researchers to verify and address any potential vulnerabilities that are reported to us. Please review these terms before you test and/or report a vulnerability. Slack pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.\n\n##Eligibility for the Bug Bounty Program\n\nWe are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Slack. However, only those researchers that meet the following criteria may be eligible to receive a reward. Some of the requirements to participate in the Bug Bounty Program include:\n\n\n* You must be the first reporter of a vulnerability associated with a participating service (we will also not reward for a known vulnerability which we are actively fixing)\n* You must have personally discovered the vulnerability and you may not report a vulnerability that was discovered by another person (including, and especially, someone who does not qualify to participate in the Bug Bounty Program)\n* You must not be employed by Slack, Salesforce, its subsidiaries, or any related entities, currently or in the last 12 months.\n* You must comply with this Policy when discovering the vulnerability and submitting the vulnerability report\n* Slack or HackerOne can’t be legally prohibited from rewarding you for any reason\n* Non-automated testing is allowed on production Slack infrastructure, preferably using dedicated test teams. Any testing for cross-team vulnerabilities should be conducted using dedicated teams created and owned by the researcher.\n\n##Conduct Guidelines\n\n\nWhile we encourage you to discover and report any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited and will result in disqualification from the Bug Bounty Program. By submitting a report to this program you agree to adhere to these guidelines. \n\n\n* Disclosing any vulnerabilities or suspected vulnerabilities you discover to any other person without explicit Salesforce authorization\n* Disclosing the contents of any submission to this program without explicit Slack authorization\n* Accessing private information of any person stored on a Slack product or service – You must use test accounts\n* Accessing sensitive information (e.g. credentials)\n* Performing actions that may negatively affect Salesforce system performance or its users (e.g. Spam, Phishing, Brute force, Distributed Denial of Service (DDoS))\n* Conducting any kind of physical attack on Slack personnel, property or data centers\n* Social engineering any Slack employee or contractor\n* Conducting vulnerability testing of participating services using anything other than test accounts (e.g. Developer or Trial Edition instances)\n* Exfiltrating data. Please test only the minimum necessary to validate a vulnerability (we can verify if data exfiltration would be possible from a vulnerability, and will reward with the impact in mind)\n* Violating any laws or breaching any agreements in order to discover vulnerabilities\n\nIf you are testing a publicly viewable area of Slack, please remove any test posts or accounts when you are done and refrain from engaging with actual users.\n\n##Disclosure Guidelines\n \nAs of August 15th, 2025, all Disclosure via HackerOne is paused for Slack. Researchers should expect all open and future requests for Mutual Disclosure to be closed until further notice. We will be taking this opportunity to align with our Salesforce bug bounty partners and provide a better experience for our researchers. There are no changes to the requirements for external disclosure outside of HackerOne.\n\nPublic disclosure of any submission to this program outside of the HackerOne platform (e.g. blogs, conference talks, research papers) requires explicit Slack approval regardless of the report status. Any form of public disclosure without explicit approval is considered a violation of our Conduct Guidelines. Please use the request disclosure option and specify that you are requesting to disclose externally. \n\n\n##Our Commitment to Researchers\n\n\nIf you submit a vulnerability report, the Slack security team and associated development organizations will use reasonable efforts to:\n\n\n\n* Respond in a timely manner, acknowledging receipt of your vulnerability report.\n* Investigate and consider your vulnerability report for eligibility under our Bug Bounty Program within 30 days of submission or less.\n* Notify you when the remediation or other action regarding the vulnerability has been implemented. \n\nSlack Products/Services In Scope for HackerOne Security Researchers\n\nThe Bug Bounty Program is limited to Slack products as specified within the *scope* section in HackerOne.\n\n\n\n##Qualifying Vulnerabilities \u0026 Bounties (In Scope)\n\n\nThe decision to grant a reward for a vulnerability report, and the value of a reward (if any), is entirely within Salesforce’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the *impact and severity* of the reported vulnerability. Keep in mind that while a report may identify a valid security concern, it must be a qualifying vulnerability as outlined below for acceptance under this program.\n\n\n* You will qualify for consideration for a reward only if you are the first person to responsibly disclose an unknown vulnerability to us in accordance with these policies. The determination of whether you are the first person is solely within our responsibility. Vulnerabilities must also be relevant, exploitable, and well-documented in the vulnerability report. We are more likely to grant a reward if the vulnerability is specific, fixable and not currently exploited against us or our customers. \n\n##Vulnerability Severity Definitions\n\nThe following vulnerability severity definitions are based on internal Salesforce documentation. These definitions are a work in progress. The goal of adding these definitions to our policy is to: \n\n* Allow more efficient report triage\n* Align directly with internal Salesforce vulnerability ranking definitions\n* Remove ambiguity and subjective assignment of severity\n* Promote fair bounty payments\n* Promote researcher satisfaction\n\nIf you have feedback and/or suggestions to help us make these more clear and useful, please email your ideas to bugbountymanager@salesforce.com\n\n###Critical\n\n* Indicators of a ‘Critical’ severity level include but are not limited to vulnerabilities that:\n    * can affect a customer-facing or Slack production asset, or a non-production environment containing production customer data. Such an impact could be the compromise of the confidentiality, integrity of availability of such an asset or data.\n    * can result in compromise of sensitive systems or customer data without user interaction.\n    * can be exploited externally / via an untrusted network.\n    * can be remotely exploited with minimal knowledge, skill, or complexity.\n    * results in a root-level compromise of servers or infrastructure devices when exploited.\n    * have a CVSS or VPR score of 9.0 or greater.\n* Examples include, but are not limited to:\n    * External Remote Code Execution (RCE): Executing potentially harmful code on a server from outside the network that may result in system compromise and possible data exfiltration, depending on the specific implementation and context.\n    * Critical Data Exposure (Single/Cross-Tenant): Potential unauthorized disclosure of sensitive data that could affect one or multiple customers, with impact varying based on data sensitivity and scope of exposure.\n    * Arbitrary Account Takeover: Potentially gaining significant control of user accounts without proper authorization, where the impact depends on the account type and associated permissions.\n    * Privilege Escalation to Root/Admin: Possible elevation of privileges to higher levels on a system that could lead to varying degrees of control over the affected system or infrastructure.\n    * Exploitation of Publicly Known and Actively Exploited Vulnerabilities: Potentially leveraging known flaws that may be under active attack, where impact varies based on the vulnerability context. The Public Disclosure must be older than 30 days if the risk is Critical.\n    * External Logic Flaws Causing Significant Service Disruption: Possible abuse of application logic accessible externally that might cause service disruptions, with impact varying based on affected business functions and duration.\n\n\n###High\n\n* Indicators of a ‘High’ severity level include but are not limited to vulnerabilities that:\n    * can affect production or customer-facing assets, or non-production environments with sensitive data.\n    * allow unauthorized access or modification of sensitive data or elevated privileges, but require more skill or context than Critical vulnerabilities.\n    * allow local users to gain increased privileges.\n    * result in susceptibility to an external, simply executed, single actor, logic-based attacks resulting in significant performance degradation of one or more critical systems/products.\n    * Can be exploited with moderate technical knowledge or skill, and is likely to result in system compromise or denial of service. Example: A publicly available exploit without evidence of active exploitation, or a proof-of-concept exploit.\n    * Have a CVSS or VPR score between 7.0 and 8.9\n* Examples include, but are not limited to:\n    * Privilege Escalation (Limited Scope): Gaining higher access within the application allowing unauthorized access to sensitive data and functionalities.\n    * External Persistent/Stored Cross-Site Scripting (XSS): Permanently injecting malicious scripts into a website, affecting other users potentially leading to session hijacking or defacement.\n    * External Cross-Site Request Forgery (CSRF) on Sensitive Functions: Forcing a user to perform unwanted actions on a web application leading to unauthorized state changes or data manipulation.\n    * External Exposure of Sensitive Information via Stack Traces: Revealing internal application details in error messages potentially leading to sensitive information leakage.\n    * Internal Use of Weak Cryptography (Practically Exploitable): Using breakable encryption within the internal network potentially leading to confidential data disclosure.\n    * Internal Remote Arbitrary Code Execution (Without Mitigating Circumstances): Executing code on an internal server potentially leading to system compromise or partial service disruption.\n    * Internal Command or SQL Injection (Without Mitigating Circumstances): Injecting malicious commands into an internal system or database allowing unauthorized data access/modification/deletion.\n    * Internal Exposure of Sensitive Information: Unauthorized access to data by internal users potentially leading to data breach or privacy violations.\n    * Internal Use of Default or Weak Credentials: Using easily guessed passwords for internal systems allowing unauthorized system access.\n    * Susceptibility to Publicly Disclosed Vulnerabilities (High Impact): Using software with known, dangerous flaws potentially leading to system compromise or data loss.\n    * External Path Traversal: Accessing restricted files or directories on the server from the outside potentially leading to access to sensitive files or code execution.\n    * Server-Side Request Forgery (SSRF): Forcing the server to make requests to unintended locations potentially leading to access to internal services or data exfiltration.\n    * Unrestricted File Upload (High Risk): Uploading files without proper security checks potentially leading to remote code execution or defacement.\n    * XML External Entity (XXE) Injection: Exploiting vulnerabilities in XML processing potentially leading to confidential data disclosure or remote code execution.\n\n\n###Medium\n\n* Indicators of a ‘Medium’ severity level include but are not limited to vulnerabilities that:\n    * may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances.  Such a difficulty could require significant knowledge or skill to exploit, or there may be controls in place to prevent exploitation.\n    * could have had a critical or high impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.\n    * require significant user interaction or chaining with other bugs to escalate impact.\n    * result in susceptibility to external, simply executed, single actor, logic-based attacks resulting in some measurable performance degradation of one or more critical systems/products.\n    * may involve low-sensitivity data or present a limited attack surface.\n    * have a CVSS or VPR score between 4.0 and 6.9.\n* Examples include, but are not limited to:\n    * External Unintended Internal Information Disclosure: Revealing internal details to external users potentially aiding further attacks.\n    * Internal Network/Application Cross-Site Scripting (XSS): Injecting malicious scripts into an internal web application potentially allowing attackers to hijack user sessions or deface internal applications.\n    * Internal Network/Application Cross-Site Request Forgery (CSRF): Forcing an authenticated internal user to perform unwanted actions potentially leading to unauthorized actions on internal applications.\n    * Internal Use of Weak Cryptography (Practically Exploitable by Sophisticated Actors): Using breakable encryption within the internal network potentially allowing sensitive internal data decryption.\n    * Usage of End-of-Life (EoL) Operating Systems or Software (Internal): Running unsupported software on internal systems increasing susceptibility to known vulnerabilities.\n    * External Facing Content Spoofing: Manipulating content to deceive users potentially leading to phishing or reputational damage.\n    * Cleartext Transmission of Sensitive Internal Data: Sending unencrypted sensitive data within the internal network potentially allowing interception of confidential internal data.\n    * Predictable Session Identifiers (Internal): Using easily guessable session tokens within the internal network potentially allowing attackers to hijack legitimate user sessions.\n    * Denial-of-Service (DoS) via Logic Flaws (Single Actor, Simple Execution, Measurable Performance Degradation): Causing a noticeable slowdown or temporary unavailability of a service with minimal effort.\n    * Path Traversal on Internal Resources: Accessing restricted files or directories within the internal network potentially allowing unauthorized access to sensitive internal configuration files or data.\n    * Missing or Ineffective Rate Limiting on Non-Critical Internal Endpoints: Failing to limit requests to certain internal features potentially leading to resource exhaustion. While researchers should always feel free to report discoveries to our program, we will only accept and pay for valid Medium severity issues related to CVEs 6 months past publish date.\n\n###Low\n\n* Indicators of a ‘Low’ severity level includes but is not limited to vulnerabilities that:\n    * do not expose sensitive data or infrastructure.\n    * represent best practice gaps, low-impact misconfigurations, or non-exploitable flaws.\n    * may be more difficult to exploit but could lead to minimal compromise of the confidentiality, integrity, or availability of resources under unlikely circumstances.\n    * require unlikely circumstances to be able to be exploited, or where a successful exploit would have minimal consequences.\n    * require complex prerequisites or attacker access to internal environments.\n    * results in susceptibility to external, simply executed, single actor, logic-based attacks resulting in minor performance degradation of one or more critical systems/products.\n    * have a CVSS or VPR score less than 4.0.\n* Examples include, but are not limited to:\n    * Cross-Site Scripting (XSS) from an Authenticated Customer Admin: Injecting malicious scripts through an admin account potentially leading to minor data theft or defacement within admin scope.\n    * Exposure of Internal Default Pages (e.g., Apache server-status): Revealing server information through standard configuration pages potentially aiding reconnaissance.\n    * Exposure of Server Configuration Information: Leaking details about the server setup slightly increasing attack surface knowledge.\n    * Use of Weak Cryptography Not Practically Exploitable: Using breakable encryption with mitigating factors presenting negligible real-world risk.\n    * External Cross-Site Request Forgery (CSRF) on Non-Sensitive Functions: Forcing a user to perform unimportant actions on a website potentially leading to unwanted minor actions.\n    * Documentation Bugs Revealing Sensitive but Outdated Information: Documentation inaccuracies that, from a security perspective, misrepresent product behavior, including instances where outdated information could reveal sensitive configurations and cause confusion.\n    * HTTP Public Key Pinning (HPKP) Configuration Errors with Fallback: Misconfiguration of certificate pinning with a working backup indicating a configuration issue.\n    * Verbose Error Messages Revealing Non-Sensitive Information: Detailed error outputs exposing internal application structure or non-critical data. The data exposed must be, at some point, important from a security perspective.\n    * Absence of Rate Limiting on Non-Authentication Related, Low-Impact Features: Lack of request limits on unimportant features potentially leading to minor resource exhaustion.\n    * Information Disclosure Through Non-Standard HTTP Headers: Revealing minor information in HTTP headers slightly increasing knowledge for attackers.\n\n\n##Qualifying Vulnerability Descriptions\n\n\n| Category | Description |\n| --- | --- |\n| Remote Code Execution | CWE-94: AKA \"Arbitrary Code Execution\".  Describes a security bug that allows an attacker to execute arbitrary commands or code on a target machine or in a target process. The exploit PoC may include many other vulnerability types, but ultimately the result is p0wnage of the server(s) and/or environment.  [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Disclosure of Credit Card data | CWE-359:  This is self-explanatory. Any security bug which allows disclosure of credit card information to an unauthorized user or system qualifies as Disclosure of Credit Card Data |\n| SQL Injection | CWE-1027:  SQL injection is a code injection technique in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Unrestricted XXE / File System Access | CWE-611:  External XML Entity Injection (XXE) is a specific type of Server Side Request Forgery(SSRF) which affects an XML processing engine server-side on a target. Specifically, blind XXE is when the results are either error-based or cause 3rd party interaction with services such as HTTP, FTP \u0026 DNS. An XXE attack typically occurs when XML input containing a reference to an external entity is processed by a weakly configured parser. An attacker can leverage an XXE attack to access sensitive data and read local or remote files. In a similar manner to SSRF, an attacker could introduce malicious code through Remote Code Execution (RCE).  [scr: https://blog.zsec.uk/out-of-band-xxe-2/]  [src: https://chris-young.net/2018/04/13/xxe-xml-external-entity/] |\n| Significant Authentication Bypass | CWE-305:  Authentication bypass is a vulnerability that allows an attacker access to credential protected resources without first acquiring valid credentials. Examples of this vulnerability include:* SQL injection during login to bypasses credential authentication* Direct access to resources normally beyond an authentication mechanism, such as a login screen, which do not independently validate the users authenticated session.* Failure to enumerate and enforce the systems' access policy. * A weak authentication system that allows a valid identity to be forged. | \n| Significant Authorization Bypass | CWE-285:  Authorization is the concept of allowing access to resources only to those permitted to use them. Vulnerabilities that bypass authorization checks may allow access to protected resources beyond what was intended by the system. Examples of authorization bypass include Insecure Direct Object Reference and Session Token Alteration. In each of these examples, the system trusts the users' requests because of improper or insecure implementation. |\n| Cross Instance Privilege Escalation | Salesforce is a multi-tenant platform in which \"instances\" are created for each Org. A cross-instance privilege escalation involves some user in instance A having access to data in instance B without proper authorization. |\n| Denial of Service | Susceptibility to an external, simply executed, single actor, logic-based attack resulting in a service outage or significant performance degradation of one or more critical systems/products  |\n| Disclosure of Personal Identifiable Information | CWE-200:  Personally identifiable information, or PII, is any data that could potentially be used to identify a particular person. As it relates to Salesforce, PII Disclosure bugs involve PII data stored within any in-scope platforms, excluding Salesforce Employee data such as Name and Contact information.  [src: https://www.lifelock.com/learn-identity-theft-resources-what-is-personally-identifiable-information.html] |\n| Salesforce Platform Misconfiguration and/or Custom APEX Vulnerabilities (Salesforce Owned/Controlled) | The Salesforce Platform is highly configurable, customizable, and supports custom code in the form of APEX code, Visualforce pages, etc. It is therefore capable of being misconfigured in such a way as to leak information or to otherwise be insecure. This category of vulnerability is specific to Salesforce owned and operated sites, NOT Salesforce customer-owned and operated Salesforce instances. If you identify a configuration vulnerability in a customer site please report it to that company via their Bug Bounty program or their security@\u003csome company dot com\u003e email address. There is no guarantee that the customer will respond to your email or bug submission, and it is out of Salesforce control. Please do not expect Salesforce to handle reports of customer misconfiguration.|\n| Privilege Escalation / Improper Access Control | Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in a software application to gain elevated access to resources that are normally protected from an application or user. The result is that a user with more privileges than intended by the application developer or system administrator can perform unauthorized actions. Note that Privilege Escalation is different from Permission Model Circumvention in that PE involves accessing functionality beyond that assigned to a given role, or somehow adding resource permissions to a given role without authorization, while PMC involves a complete bypass of security controls meant to enforce permissions. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access.  [src: https://en.wikipedia.org/wiki/Privilege_escalation] |\n| Non-XXE SSRF | In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.[src:https://www.owasp.org/index.php/Server_Side_Request_Forgery] |\n| Insecure Direct Object Reference | IDOR occurs when unvalidated user-supplied input is submitted and direct access to the object requested is provided. Vulnerability reports for IDOR are valid when the result is unauthorized information disclosure, modification or destruction of data, or performing a function outside of the limits of the current user. |\n| CRLF injection/HTTP response splitting  | HTTP response splitting occurs when data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. [src: https://www.owasp.org/index.php/HTTP_Response_Splitting] |\n| Circumvention of our Platform’s Permission Model | Permission Model Circumvention involves a complete bypass of security controls meant to enforce permissions. An example of PMC involves an insecurely configured system in which an API gateway fronts for several servers and implements authentication/authorization. The configuration is such that the URI to the backend servers can be identified and they are directly accessible without any additional authentication or authorization checks..While there is an authX model in place, it was trivially circumventable. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access. |\n| Cross-Site Scripting (excluding self-XSS) | CWE-80:  Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. [src:https://en.wikipedia.org/wiki/Cross-site_scripting] |\n| Cross-Site Request Forgery (CSRF) on critical actions | CWE-352:  Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.  [src: https://en.wikipedia.org/wiki/Cross-site_request_forgery] |\n| Insufficiently Protected Credentials / Credential Exposure | CWE-522:  CWE-522: Within the context of the Salesforce/HackerOne Bug Bounty program, credential exposure involves finding, or gaining access to a user or system credentials which are not meant to be public. An example of IPC would be finding a Github or other repo containing configuration files that contain usernames, passwords, API keys, private keys, etc. Another example is an exposure of a single user's credentials on the querystring, in cookies, or in other HTTP headers. |\n| Insecure/Open Redirect | CWE-601:  An HTTP parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. |\n| DNS Hijacking / Subdomain Takeover | DNS hijacking or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries.The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.  [src: https://en.wikipedia.org/wiki/DNS_hijacking] [src: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers] |\n| Configuration/Stats//Log File Exposure | CWE-532 Information Exposure Through Log Files. CWE-200: Information Exposure. Any instance in which log files or server/application configuration files are accessible when they are not meant to be. |\n| Documentation Bug | Any instance in which, from a strictly security-based perspective, the published documentation is incorrect with regard to the behavior of the product. | \n\n\n##Non-Qualifying Vulnerabilities (Out of Scope)\n\n\nThe following types of issues are *specifically excluded* from our Bug Bounty Program:\n\n- Attacks requiring physical access to a user's unlocked device\n- Reports of spam, phishing or security best practices\n- Bugs categorized as P3 (low risk)\n- Clickjacking and issues only exploitable through clickjacking\n* CSRF-able actions that do not require authentication (or a session) to exploit or CSRF issues which have no security impact to Slack.\n* HTML and Link injections\n* Issues related to \"Editable Github Wiki Pages\"\n* Issues related to Salesforce *Partner* User Credential Disclosure in public code repositories such as GitHub. *Please note that this type of activity is explicitly excluded by the Conduct Guidelines in this policy.*\n* TOCTOU bugs involving platform permission changes. For example; User A has an active session, Admin reduces or increases permissions for User A, User A permissions do not change until User A logs out and back in. This is currently WAD on Salesforce platforms.\n* Invalid links from any Salesforce site to any social media site in which a claim of \"account takeover\" or \"possible phishing attacks\" are the basis for the report.\n* Bugs in content/services that are not owned/operated by Salesforce\n* Vulnerabilities affecting users of outdated or unsupported browsers or platforms\n* Vulnerabilities that have already been addressed in a product update regardless of whether the update has been applied to the publicly available research machines\n* Subdomain takeovers for out of scope domains\n* Self-XSS or XSS bugs requiring an unlikely amount of user interaction\n* XSS in our content sandbox under .content.force.com (http://content.force.com/)\n- XSS under \\.sitepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.livepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.visual.force.com (with the exception of Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n* XSS in custom apps under .force.com (with the exception of lightning.force.com and Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n- Descriptive error messages (e.g. Stack Traces, application or server errors)\n- HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n- Fingerprinting / banner disclosure on common/public services.\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Scripting or other automation and brute-forcing of intended functionality\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n- Lack of Secure and HTTPOnly cookie flags\n- Content spoofing (text injection) or IDN homograph attacks\n- Tabnabbing \n- Email configuration issues (SPF, DKIM, DMARC)\n- Weak Captcha / Captcha Bypass\n- Forced Login / Logout CSRF\n- Account lockout, Login or Forgot Password page brute force\n- Password complexity or account recovery policies\n- Username / email enumeration (brute force)\n- HTTPS Mixed Content\n- Missing HTTP security headers, specifically: Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy.\n- OPTIONS HTTP method enabled\n- Known SSL issues (e.g. attacks such as BEAST, BREACH, POODLE, TLS Renegotiation)\n- SSL Forward Secrecy or HSTS not enabled\n- Weak SSL/TLS Cipher Suites\n- CSV Excel Formula injection\n- Issues related to networking protocols or industry standards not controlled by Salesforce\n- Sending vulnerability reports using automated tools without validation\n- Use of a known-vulnerable library without evidence of exploitability\n- Reflected XSS involving Adobe Flash files (.swf)\n\n*If you are unsure whether a bug or issue that you discover in a participating service is a non-qualifying vulnerability, please email us at \u003cbugbountymanager@salesforce.com\u003e*\n\n\n_Intellectual Property_\n\n\nParticipating in the Bug Bounty Program does not grant to you or any other third party any rights to any Slack or Salesforce intellectual property, product or service. All rights not otherwise granted herein are expressly reserved. Whether or not we grant you a reward, you hereby assign to Salesforce all right, title and interest (including all intellectual property rights), in the contents of all vulnerability reports that you submit to Salesforce. \n\nBy participating in the Bug Bounty Program, you represent that you have the right to assign all such right, title and interest to us and that your participation in the Bug Bounty Program and assignment of such right, title and interest will not breach any agreement you may have with a third party (e.g. your employer).\n\n\n_Other Terms and Conditions_\n\n\nSalesforce pledges not to pursue a civil action or initiate a complaint to law enforcement against researchers for security research and vulnerability disclosure activities conducted in accordance with this Policy. We consider security research and vulnerability disclosure activities conducted in accordance with this Policy “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA and applicable anti-hacking laws such as Cal. Penal Code 502(c). We waive any DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy.\n\nBy participating in the Bug Bounty Program, you agree to be bound by these rules. These policies will apply to you in addition to, and will not replace, any other terms and conditions that are imposed by HackerOne.\n\n- Your participation in the Bug Bounty Program does not create any kind of employment relationship or partnership between you and Salesforce. You must not hold yourself out as a Salesforce employee or as someone in any way affiliated with Salesforce.\n- You must comply with all applicable laws in connection with your participation in this program. \n- You are responsible for any applicable taxes associated with any reward you receive. \n- Vulnerability reports received prior to the Bug Bounty Program launch are not eligible for rewards and may not be re-submitted for a reward.\n- You will not use any of our trademarks, service marks and logos.\n- We may modify this Policy at any time by posting an updated version of this document.\n- We may terminate this Bug Bounty Program at any time without notice. \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":"2025-08-25T22:10:53.200Z"},{"id":3761212,"new_policy":"## Slack Technologies, LLC, a Salesforce company\n\nOver _$12M_ in bounties awarded across all our H1 Bug Bounty programs since 2015!\n\nAt Slack, a Salesforce company, Trust is our #1 value and we take the protection of our customers' data very seriously. We encourage responsible reporting and disclosure of any vulnerabilities found in Slack services outlined in our Scope section.\n\nSlack is committed to working with security researchers to verify and address any potential vulnerabilities that are reported to us. Please review these terms before you test and/or report a vulnerability. Slack pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.\n\n##Eligibility for the Bug Bounty Program\n\nWe are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Slack. However, only those researchers that meet the following criteria may be eligible to receive a reward. Some of the requirements to participate in the Bug Bounty Program include:\n\n\n* You must be the first reporter of a vulnerability associated with a participating service (we will also not reward for a known vulnerability which we are actively fixing)\n* You must have personally discovered the vulnerability and you may not report a vulnerability that was discovered by another person (including, and especially, someone who does not qualify to participate in the Bug Bounty Program)\n* You must not be employed by Slack, Salesforce, its subsidiaries, or any related entities, currently or in the last 12 months.\n* You must comply with this Policy when discovering the vulnerability and submitting the vulnerability report\n* Slack or HackerOne can’t be legally prohibited from rewarding you for any reason\n* Non-automated testing is allowed on production Slack infrastructure, preferably using dedicated test teams. Any testing for cross-team vulnerabilities should be conducted using dedicated teams created and owned by the researcher.\n\n##Conduct Guidelines\n\n\nWhile we encourage you to discover and report any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited and will result in disqualification from the Bug Bounty Program. By submitting a report to this program you agree to adhere to these guidelines. \n\n\n* Disclosing any vulnerabilities or suspected vulnerabilities you discover to any other person without explicit Salesforce authorization\n* Disclosing the contents of any submission to this program without explicit Slack authorization\n* Accessing private information of any person stored on a Slack product or service – You must use test accounts\n* Accessing sensitive information (e.g. credentials)\n* Performing actions that may negatively affect Salesforce system performance or its users (e.g. Spam, Phishing, Brute force, Distributed Denial of Service (DDoS))\n* Conducting any kind of physical attack on Slack personnel, property or data centers\n* Social engineering any Slack employee or contractor\n* Conducting vulnerability testing of participating services using anything other than test accounts (e.g. Developer or Trial Edition instances)\n* Exfiltrating data. Please test only the minimum necessary to validate a vulnerability (we can verify if data exfiltration would be possible from a vulnerability, and will reward with the impact in mind)\n* Violating any laws or breaching any agreements in order to discover vulnerabilities\n\nIf you are testing a publicly viewable area of Slack, please remove any test posts or accounts when you are done and refrain from engaging with actual users.\n\n##Disclosure Guidelines\n \nAs of August 15th, 2025, all Disclosure via HackerOne is paused for Slack. Researchers should expect all open and future requests for Mutual Disclosure to be closed until further notice. We will be taking this opportunity to align with our Salesforce bug bounty partners and provide a better experience for our researchers. There are no changes to the requirements for external disclosure outside of HackerOne.\n\nPublic disclosure of any submission to this program outside of the HackerOne platform (e.g. blogs, conference talks, research papers) requires explicit Slack approval regardless of the report status. Any form of public disclosure without explicit approval is considered a violation of our Conduct Guidelines. Please use the request disclosure option and specify that you are requesting to disclose externally. \n\n\n##Our Commitment to Researchers\n\n\nIf you submit a vulnerability report, the Slack security team and associated development organizations will use reasonable efforts to:\n\n\n\n* Respond in a timely manner, acknowledging receipt of your vulnerability report.\n* Investigate and consider your vulnerability report for eligibility under our Bug Bounty Program within 30 days of submission or less.\n* Notify you when the remediation or other action regarding the vulnerability has been implemented. \n\nSlack Products/Services In Scope for HackerOne Security Researchers\n\nThe Bug Bounty Program is limited to Slack products as specified within the *scope* section in HackerOne.\n\n\n\n##Qualifying Vulnerabilities \u0026 Bounties (In Scope)\n\n\nThe decision to grant a reward for a vulnerability report, and the value of a reward (if any), is entirely within Salesforce’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the *impact and severity* of the reported vulnerability. Keep in mind that while a report may identify a valid security concern, it must be a qualifying vulnerability as outlined below for acceptance under this program.\n\n\n* You will qualify for consideration for a reward only if you are the first person to responsibly disclose an unknown vulnerability to us in accordance with these policies. The determination of whether you are the first person is solely within our responsibility. Vulnerabilities must also be relevant, exploitable, and well-documented in the vulnerability report. We are more likely to grant a reward if the vulnerability is specific, fixable and not currently exploited against us or our customers. \n\nThe following table lists our target reward range for different types of vulnerabilities within the published scope. All other vulnerabilities not on this table will also be considered and awarded a bounty on a case by case basis. Additional bounty may be awarded on top of these base amounts, as determined by the Bug Bounty management team.\n\n###The bounty values provided are subject to change at any time as determined by Salesforce.\n\n|Vulnerability Type | Critical | High | Medium | Low |\n| --- | --- | --- | --- | --- |\n|Authentication Bypass (Cross Org) |\t$10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Authentication Bypass (Same Org) |\t$9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Authorization Bypass / Privilege Escalation (Cross Org) |\t$10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Authorization Bypass / Privilege Escalation (Same Org) | $9,000 | $6,000 | $1,500 | $500 |\n|Circumvention of our Platform’s Permission Model (Cross Org) | $10,000 |\t$7,000 |\t$2,000 |$500 |\n|Circumvention of our Platform’s Permission Model (Same Org) |\t$9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Configuration/Stats//Log File Exposure |\t$5,000 |\t$2,500 |\t$1,000 |\t$250 |\n|CRLF injection/HTTP response splitting |\t$4,000 |\t$2,500 |\t$1,000 |\t$500 |\n|Cross Site Request Forgery (CSRF) |\tN/A | $2,500 | $1,000 | $250 |\n|Cross-Site Scripting (excluding self-XSS) | $5,000 | $3,500 | $1,000 | $250 |\n|Denial of Service | $7,000 |\t$4,000 |\t$1,000 |\t$500 |\n|Disclosure of Credit Card data |\t$14,000 |\t$11,000 |\t$6,000 |\t$500 |\n|Disclosure of Personal Identifiable Information |\t$500 |\t$500 |\t$500 |\t$500 |\n|DNS Hijacking / Subdomain Takeover | $5,000 |\t$2,500 |\t$500 |\t$250 |\n|Documentation Bug | N/A |\tN/A |\tN/A |\t$250 |\n|Excessive Agency |\t$12,000 |\t$9,000 |\t$5,000 |\t$500 |\n|Improper Access Control (Cross Org) |\t$10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Improper Access Control (Same Org) |\t$9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Insecure Direct Object Reference (IDOR) (Cross Org) | $10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Insecure Direct Object Reference (IDOR) (Same Org) | $9,000 | $6,000 |\t$1,500 |\t$500 |\n|Insecure Redirect |\tN/A |\tN/A | $1,000 |\t$250 |\n|Insufficiently Protected Credentials / Credential Exposure |\t$5,000 |\t$2,500 |\t$1,000 |\t$250 |\n|Model Theft |\t$12,000 |\t$9,000 |\t$5,000 |\t$500 |\n|Non-XXE SSRF |\t$5,000 |\t$3,500 |\t$1,500 |\t$500 |\n|Other Information Disclosure |\t$5,000 |\t$2,500 |\t$1,000 |\t$250 |\n|Other Injection (SOQL, Command Injection, RFI, LFI, etc.) | $9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Prompt Injection |\t$20,000 |\t$15,000 |\t$5,000 |\t$500 |\n|Remote Code Execution |\t$17,000 |\t$13,000 | $8,000 |\t$500 |\n|Salesforce-Owned/Controlled Misconfiguration and/or Custom APEX Vulnerabilities | $5,000 |\t$2,500 |\t$1,000 |\t$500 |\n|SQL Injection | $12,000 |\t$9,000 |\t$5,000 |\t$500 |\n|Unrestricted XXE / File System Access |\t$10,500 |\t$7,000 |\t$4,500 |\t$500 |\n\n##Vulnerability Severity Definitions\n\nThe following vulnerability severity definitions are based on internal Salesforce documentation. These definitions are a work in progress. The goal of adding these definitions to our policy is to: \n\n* Allow more efficient report triage\n* Align directly with internal Salesforce vulnerability ranking definitions\n* Remove ambiguity and subjective assignment of severity\n* Promote fair bounty payments\n* Promote researcher satisfaction\n\nIf you have feedback and/or suggestions to help us make these more clear and useful, please email your ideas to bugbountymanager@salesforce.com\n\n###Critical\n\n* Indicators of a ‘Critical’ severity level include but are not limited to vulnerabilities that:\n    * can affect a customer-facing or Slack production asset, or a non-production environment containing production customer data. Such an impact could be the compromise of the confidentiality, integrity of availability of such an asset or data.\n    * can result in compromise of sensitive systems or customer data without user interaction.\n    * can be exploited externally / via an untrusted network.\n    * can be remotely exploited with minimal knowledge, skill, or complexity.\n    * results in a root-level compromise of servers or infrastructure devices when exploited.\n    * have a CVSS or VPR score of 9.0 or greater.\n* Examples include, but are not limited to:\n    * External Remote Code Execution (RCE): Executing potentially harmful code on a server from outside the network that may result in system compromise and possible data exfiltration, depending on the specific implementation and context.\n    * Critical Data Exposure (Single/Cross-Tenant): Potential unauthorized disclosure of sensitive data that could affect one or multiple customers, with impact varying based on data sensitivity and scope of exposure.\n    * Arbitrary Account Takeover: Potentially gaining significant control of user accounts without proper authorization, where the impact depends on the account type and associated permissions.\n    * Privilege Escalation to Root/Admin: Possible elevation of privileges to higher levels on a system that could lead to varying degrees of control over the affected system or infrastructure.\n    * Exploitation of Publicly Known and Actively Exploited Vulnerabilities: Potentially leveraging known flaws that may be under active attack, where impact varies based on the vulnerability context. The Public Disclosure must be older than 30 days if the risk is Critical.\n    * External Logic Flaws Causing Significant Service Disruption: Possible abuse of application logic accessible externally that might cause service disruptions, with impact varying based on affected business functions and duration.\n\n\n###High\n\n* Indicators of a ‘High’ severity level include but are not limited to vulnerabilities that:\n    * can affect production or customer-facing assets, or non-production environments with sensitive data.\n    * allow unauthorized access or modification of sensitive data or elevated privileges, but require more skill or context than Critical vulnerabilities.\n    * allow local users to gain increased privileges.\n    * result in susceptibility to an external, simply executed, single actor, logic-based attacks resulting in significant performance degradation of one or more critical systems/products.\n    * Can be exploited with moderate technical knowledge or skill, and is likely to result in system compromise or denial of service. Example: A publicly available exploit without evidence of active exploitation, or a proof-of-concept exploit.\n    * Have a CVSS or VPR score between 7.0 and 8.9\n* Examples include, but are not limited to:\n    * Privilege Escalation (Limited Scope): Gaining higher access within the application allowing unauthorized access to sensitive data and functionalities.\n    * External Persistent/Stored Cross-Site Scripting (XSS): Permanently injecting malicious scripts into a website, affecting other users potentially leading to session hijacking or defacement.\n    * External Cross-Site Request Forgery (CSRF) on Sensitive Functions: Forcing a user to perform unwanted actions on a web application leading to unauthorized state changes or data manipulation.\n    * External Exposure of Sensitive Information via Stack Traces: Revealing internal application details in error messages potentially leading to sensitive information leakage.\n    * Internal Use of Weak Cryptography (Practically Exploitable): Using breakable encryption within the internal network potentially leading to confidential data disclosure.\n    * Internal Remote Arbitrary Code Execution (Without Mitigating Circumstances): Executing code on an internal server potentially leading to system compromise or partial service disruption.\n    * Internal Command or SQL Injection (Without Mitigating Circumstances): Injecting malicious commands into an internal system or database allowing unauthorized data access/modification/deletion.\n    * Internal Exposure of Sensitive Information: Unauthorized access to data by internal users potentially leading to data breach or privacy violations.\n    * Internal Use of Default or Weak Credentials: Using easily guessed passwords for internal systems allowing unauthorized system access.\n    * Susceptibility to Publicly Disclosed Vulnerabilities (High Impact): Using software with known, dangerous flaws potentially leading to system compromise or data loss.\n    * External Path Traversal: Accessing restricted files or directories on the server from the outside potentially leading to access to sensitive files or code execution.\n    * Server-Side Request Forgery (SSRF): Forcing the server to make requests to unintended locations potentially leading to access to internal services or data exfiltration.\n    * Unrestricted File Upload (High Risk): Uploading files without proper security checks potentially leading to remote code execution or defacement.\n    * XML External Entity (XXE) Injection: Exploiting vulnerabilities in XML processing potentially leading to confidential data disclosure or remote code execution.\n\n\n###Medium\n\n* Indicators of a ‘Medium’ severity level include but are not limited to vulnerabilities that:\n    * may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances.  Such a difficulty could require significant knowledge or skill to exploit, or there may be controls in place to prevent exploitation.\n    * could have had a critical or high impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.\n    * require significant user interaction or chaining with other bugs to escalate impact.\n    * result in susceptibility to external, simply executed, single actor, logic-based attacks resulting in some measurable performance degradation of one or more critical systems/products.\n    * may involve low-sensitivity data or present a limited attack surface.\n    * have a CVSS or VPR score between 4.0 and 6.9.\n* Examples include, but are not limited to:\n    * External Unintended Internal Information Disclosure: Revealing internal details to external users potentially aiding further attacks.\n    * Internal Network/Application Cross-Site Scripting (XSS): Injecting malicious scripts into an internal web application potentially allowing attackers to hijack user sessions or deface internal applications.\n    * Internal Network/Application Cross-Site Request Forgery (CSRF): Forcing an authenticated internal user to perform unwanted actions potentially leading to unauthorized actions on internal applications.\n    * Internal Use of Weak Cryptography (Practically Exploitable by Sophisticated Actors): Using breakable encryption within the internal network potentially allowing sensitive internal data decryption.\n    * Usage of End-of-Life (EoL) Operating Systems or Software (Internal): Running unsupported software on internal systems increasing susceptibility to known vulnerabilities.\n    * External Facing Content Spoofing: Manipulating content to deceive users potentially leading to phishing or reputational damage.\n    * Cleartext Transmission of Sensitive Internal Data: Sending unencrypted sensitive data within the internal network potentially allowing interception of confidential internal data.\n    * Predictable Session Identifiers (Internal): Using easily guessable session tokens within the internal network potentially allowing attackers to hijack legitimate user sessions.\n    * Denial-of-Service (DoS) via Logic Flaws (Single Actor, Simple Execution, Measurable Performance Degradation): Causing a noticeable slowdown or temporary unavailability of a service with minimal effort.\n    * Path Traversal on Internal Resources: Accessing restricted files or directories within the internal network potentially allowing unauthorized access to sensitive internal configuration files or data.\n    * Missing or Ineffective Rate Limiting on Non-Critical Internal Endpoints: Failing to limit requests to certain internal features potentially leading to resource exhaustion. While researchers should always feel free to report discoveries to our program, we will only accept and pay for valid Medium severity issues related to CVEs 6 months past publish date.\n\n###Low\n\n* Indicators of a ‘Low’ severity level includes but is not limited to vulnerabilities that:\n    * do not expose sensitive data or infrastructure.\n    * represent best practice gaps, low-impact misconfigurations, or non-exploitable flaws.\n    * may be more difficult to exploit but could lead to minimal compromise of the confidentiality, integrity, or availability of resources under unlikely circumstances.\n    * require unlikely circumstances to be able to be exploited, or where a successful exploit would have minimal consequences.\n    * require complex prerequisites or attacker access to internal environments.\n    * results in susceptibility to external, simply executed, single actor, logic-based attacks resulting in minor performance degradation of one or more critical systems/products.\n    * have a CVSS or VPR score less than 4.0.\n* Examples include, but are not limited to:\n    * Cross-Site Scripting (XSS) from an Authenticated Customer Admin: Injecting malicious scripts through an admin account potentially leading to minor data theft or defacement within admin scope.\n    * Exposure of Internal Default Pages (e.g., Apache server-status): Revealing server information through standard configuration pages potentially aiding reconnaissance.\n    * Exposure of Server Configuration Information: Leaking details about the server setup slightly increasing attack surface knowledge.\n    * Use of Weak Cryptography Not Practically Exploitable: Using breakable encryption with mitigating factors presenting negligible real-world risk.\n    * External Cross-Site Request Forgery (CSRF) on Non-Sensitive Functions: Forcing a user to perform unimportant actions on a website potentially leading to unwanted minor actions.\n    * Documentation Bugs Revealing Sensitive but Outdated Information: Documentation inaccuracies that, from a security perspective, misrepresent product behavior, including instances where outdated information could reveal sensitive configurations and cause confusion.\n    * HTTP Public Key Pinning (HPKP) Configuration Errors with Fallback: Misconfiguration of certificate pinning with a working backup indicating a configuration issue.\n    * Verbose Error Messages Revealing Non-Sensitive Information: Detailed error outputs exposing internal application structure or non-critical data. The data exposed must be, at some point, important from a security perspective.\n    * Absence of Rate Limiting on Non-Authentication Related, Low-Impact Features: Lack of request limits on unimportant features potentially leading to minor resource exhaustion.\n    * Information Disclosure Through Non-Standard HTTP Headers: Revealing minor information in HTTP headers slightly increasing knowledge for attackers.\n\n\n##Qualifying Vulnerability Descriptions\n\n\n| Category | Description |\n| --- | --- |\n| Remote Code Execution | CWE-94: AKA \"Arbitrary Code Execution\".  Describes a security bug that allows an attacker to execute arbitrary commands or code on a target machine or in a target process. The exploit PoC may include many other vulnerability types, but ultimately the result is p0wnage of the server(s) and/or environment.  [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Disclosure of Credit Card data | CWE-359:  This is self-explanatory. Any security bug which allows disclosure of credit card information to an unauthorized user or system qualifies as Disclosure of Credit Card Data |\n| SQL Injection | CWE-1027:  SQL injection is a code injection technique in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Unrestricted XXE / File System Access | CWE-611:  External XML Entity Injection (XXE) is a specific type of Server Side Request Forgery(SSRF) which affects an XML processing engine server-side on a target. Specifically, blind XXE is when the results are either error-based or cause 3rd party interaction with services such as HTTP, FTP \u0026 DNS. An XXE attack typically occurs when XML input containing a reference to an external entity is processed by a weakly configured parser. An attacker can leverage an XXE attack to access sensitive data and read local or remote files. In a similar manner to SSRF, an attacker could introduce malicious code through Remote Code Execution (RCE).  [scr: https://blog.zsec.uk/out-of-band-xxe-2/]  [src: https://chris-young.net/2018/04/13/xxe-xml-external-entity/] |\n| Significant Authentication Bypass | CWE-305:  Authentication bypass is a vulnerability that allows an attacker access to credential protected resources without first acquiring valid credentials. Examples of this vulnerability include:* SQL injection during login to bypasses credential authentication* Direct access to resources normally beyond an authentication mechanism, such as a login screen, which do not independently validate the users authenticated session.* Failure to enumerate and enforce the systems' access policy. * A weak authentication system that allows a valid identity to be forged. | \n| Significant Authorization Bypass | CWE-285:  Authorization is the concept of allowing access to resources only to those permitted to use them. Vulnerabilities that bypass authorization checks may allow access to protected resources beyond what was intended by the system. Examples of authorization bypass include Insecure Direct Object Reference and Session Token Alteration. In each of these examples, the system trusts the users' requests because of improper or insecure implementation. |\n| Cross Instance Privilege Escalation | Salesforce is a multi-tenant platform in which \"instances\" are created for each Org. A cross-instance privilege escalation involves some user in instance A having access to data in instance B without proper authorization. |\n| Denial of Service | Susceptibility to an external, simply executed, single actor, logic-based attack resulting in a service outage or significant performance degradation of one or more critical systems/products  |\n| Disclosure of Personal Identifiable Information | CWE-200:  Personally identifiable information, or PII, is any data that could potentially be used to identify a particular person. As it relates to Salesforce, PII Disclosure bugs involve PII data stored within any in-scope platforms, excluding Salesforce Employee data such as Name and Contact information.  [src: https://www.lifelock.com/learn-identity-theft-resources-what-is-personally-identifiable-information.html] |\n| Salesforce Platform Misconfiguration and/or Custom APEX Vulnerabilities (Salesforce Owned/Controlled) | The Salesforce Platform is highly configurable, customizable, and supports custom code in the form of APEX code, Visualforce pages, etc. It is therefore capable of being misconfigured in such a way as to leak information or to otherwise be insecure. This category of vulnerability is specific to Salesforce owned and operated sites, NOT Salesforce customer-owned and operated Salesforce instances. If you identify a configuration vulnerability in a customer site please report it to that company via their Bug Bounty program or their security@\u003csome company dot com\u003e email address. There is no guarantee that the customer will respond to your email or bug submission, and it is out of Salesforce control. Please do not expect Salesforce to handle reports of customer misconfiguration.|\n| Privilege Escalation / Improper Access Control | Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in a software application to gain elevated access to resources that are normally protected from an application or user. The result is that a user with more privileges than intended by the application developer or system administrator can perform unauthorized actions. Note that Privilege Escalation is different from Permission Model Circumvention in that PE involves accessing functionality beyond that assigned to a given role, or somehow adding resource permissions to a given role without authorization, while PMC involves a complete bypass of security controls meant to enforce permissions. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access.  [src: https://en.wikipedia.org/wiki/Privilege_escalation] |\n| Non-XXE SSRF | In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.[src:https://www.owasp.org/index.php/Server_Side_Request_Forgery] |\n| Insecure Direct Object Reference | IDOR occurs when unvalidated user-supplied input is submitted and direct access to the object requested is provided. Vulnerability reports for IDOR are valid when the result is unauthorized information disclosure, modification or destruction of data, or performing a function outside of the limits of the current user. |\n| CRLF injection/HTTP response splitting  | HTTP response splitting occurs when data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. [src: https://www.owasp.org/index.php/HTTP_Response_Splitting] |\n| Circumvention of our Platform’s Permission Model | Permission Model Circumvention involves a complete bypass of security controls meant to enforce permissions. An example of PMC involves an insecurely configured system in which an API gateway fronts for several servers and implements authentication/authorization. The configuration is such that the URI to the backend servers can be identified and they are directly accessible without any additional authentication or authorization checks..While there is an authX model in place, it was trivially circumventable. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access. |\n| Cross-Site Scripting (excluding self-XSS) | CWE-80:  Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. [src:https://en.wikipedia.org/wiki/Cross-site_scripting] |\n| Cross-Site Request Forgery (CSRF) on critical actions | CWE-352:  Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.  [src: https://en.wikipedia.org/wiki/Cross-site_request_forgery] |\n| Insufficiently Protected Credentials / Credential Exposure | CWE-522:  CWE-522: Within the context of the Salesforce/HackerOne Bug Bounty program, credential exposure involves finding, or gaining access to a user or system credentials which are not meant to be public. An example of IPC would be finding a Github or other repo containing configuration files that contain usernames, passwords, API keys, private keys, etc. Another example is an exposure of a single user's credentials on the querystring, in cookies, or in other HTTP headers. |\n| Insecure/Open Redirect | CWE-601:  An HTTP parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. |\n| DNS Hijacking / Subdomain Takeover | DNS hijacking or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries.The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.  [src: https://en.wikipedia.org/wiki/DNS_hijacking] [src: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers] |\n| Configuration/Stats//Log File Exposure | CWE-532 Information Exposure Through Log Files. CWE-200: Information Exposure. Any instance in which log files or server/application configuration files are accessible when they are not meant to be. |\n| Documentation Bug | Any instance in which, from a strictly security-based perspective, the published documentation is incorrect with regard to the behavior of the product. | \n\n\n##Non-Qualifying Vulnerabilities (Out of Scope)\n\n\nThe following types of issues are *specifically excluded* from our Bug Bounty Program:\n\n- Attacks requiring physical access to a user's unlocked device\n- Reports of spam, phishing or security best practices\n- Bugs categorized as P3 (low risk)\n- Clickjacking and issues only exploitable through clickjacking\n* CSRF-able actions that do not require authentication (or a session) to exploit or CSRF issues which have no security impact to Slack.\n* HTML and Link injections\n* Issues related to \"Editable Github Wiki Pages\"\n* Issues related to Salesforce *Partner* User Credential Disclosure in public code repositories such as GitHub. *Please note that this type of activity is explicitly excluded by the Conduct Guidelines in this policy.*\n* TOCTOU bugs involving platform permission changes. For example; User A has an active session, Admin reduces or increases permissions for User A, User A permissions do not change until User A logs out and back in. This is currently WAD on Salesforce platforms.\n* Invalid links from any Salesforce site to any social media site in which a claim of \"account takeover\" or \"possible phishing attacks\" are the basis for the report.\n* Bugs in content/services that are not owned/operated by Salesforce\n* Vulnerabilities affecting users of outdated or unsupported browsers or platforms\n* Vulnerabilities that have already been addressed in a product update regardless of whether the update has been applied to the publicly available research machines\n* Subdomain takeovers for out of scope domains\n* Self-XSS or XSS bugs requiring an unlikely amount of user interaction\n* XSS in our content sandbox under .content.force.com (http://content.force.com/)\n- XSS under \\.sitepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.livepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.visual.force.com (with the exception of Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n* XSS in custom apps under .force.com (with the exception of lightning.force.com and Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n- Descriptive error messages (e.g. Stack Traces, application or server errors)\n- HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n- Fingerprinting / banner disclosure on common/public services.\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Scripting or other automation and brute-forcing of intended functionality\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n- Lack of Secure and HTTPOnly cookie flags\n- Content spoofing (text injection) or IDN homograph attacks\n- Tabnabbing \n- Email configuration issues (SPF, DKIM, DMARC)\n- Weak Captcha / Captcha Bypass\n- Forced Login / Logout CSRF\n- Account lockout, Login or Forgot Password page brute force\n- Password complexity or account recovery policies\n- Username / email enumeration (brute force)\n- HTTPS Mixed Content\n- Missing HTTP security headers, specifically: Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy.\n- OPTIONS HTTP method enabled\n- Known SSL issues (e.g. attacks such as BEAST, BREACH, POODLE, TLS Renegotiation)\n- SSL Forward Secrecy or HSTS not enabled\n- Weak SSL/TLS Cipher Suites\n- CSV Excel Formula injection\n- Issues related to networking protocols or industry standards not controlled by Salesforce\n- Sending vulnerability reports using automated tools without validation\n- Use of a known-vulnerable library without evidence of exploitability\n- Reflected XSS involving Adobe Flash files (.swf)\n\n*If you are unsure whether a bug or issue that you discover in a participating service is a non-qualifying vulnerability, please email us at \u003cbugbountymanager@salesforce.com\u003e*\n\n\n_Intellectual Property_\n\n\nParticipating in the Bug Bounty Program does not grant to you or any other third party any rights to any Slack or Salesforce intellectual property, product or service. All rights not otherwise granted herein are expressly reserved. Whether or not we grant you a reward, you hereby assign to Salesforce all right, title and interest (including all intellectual property rights), in the contents of all vulnerability reports that you submit to Salesforce. \n\nBy participating in the Bug Bounty Program, you represent that you have the right to assign all such right, title and interest to us and that your participation in the Bug Bounty Program and assignment of such right, title and interest will not breach any agreement you may have with a third party (e.g. your employer).\n\n\n_Other Terms and Conditions_\n\n\nSalesforce pledges not to pursue a civil action or initiate a complaint to law enforcement against researchers for security research and vulnerability disclosure activities conducted in accordance with this Policy. We consider security research and vulnerability disclosure activities conducted in accordance with this Policy “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA and applicable anti-hacking laws such as Cal. Penal Code 502(c). We waive any DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy.\n\nBy participating in the Bug Bounty Program, you agree to be bound by these rules. These policies will apply to you in addition to, and will not replace, any other terms and conditions that are imposed by HackerOne.\n\n- Your participation in the Bug Bounty Program does not create any kind of employment relationship or partnership between you and Salesforce. You must not hold yourself out as a Salesforce employee or as someone in any way affiliated with Salesforce.\n- You must comply with all applicable laws in connection with your participation in this program. \n- You are responsible for any applicable taxes associated with any reward you receive. \n- Vulnerability reports received prior to the Bug Bounty Program launch are not eligible for rewards and may not be re-submitted for a reward.\n- You will not use any of our trademarks, service marks and logos.\n- We may modify this Policy at any time by posting an updated version of this document.\n- We may terminate this Bug Bounty Program at any time without notice. \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":"2025-08-15T15:52:59.133Z"},{"id":3761211,"new_policy":"## Slack Technologies, LLC, a Salesforce company\n\nOver _$12M_ in bounties awarded across all our H1 Bug Bounty programs since 2015!\n\nAt Slack, a Salesforce company, Trust is our #1 value and we take the protection of our customers' data very seriously. We encourage responsible reporting and disclosure of any vulnerabilities found in Slack services outlined in our Scope section.\n\nSlack is committed to working with security researchers to verify and address any potential vulnerabilities that are reported to us. Please review these terms before you test and/or report a vulnerability. Slack pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.\n\n##Eligibility for the Bug Bounty Program\n\nWe are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Slack. However, only those researchers that meet the following criteria may be eligible to receive a reward. Some of the requirements to participate in the Bug Bounty Program include:\n\n\n* You must be the first reporter of a vulnerability associated with a participating service (we will also not reward for a known vulnerability which we are actively fixing)\n* You must have personally discovered the vulnerability and you may not report a vulnerability that was discovered by another person (including, and especially, someone who does not qualify to participate in the Bug Bounty Program)\n* You must not be employed by Slack, Salesforce, its subsidiaries, or any related entities, currently or in the last 12 months.\n* You must comply with this Policy when discovering the vulnerability and submitting the vulnerability report\n* Slack or HackerOne can’t be legally prohibited from rewarding you for any reason\n* Non-automated testing is allowed on production Slack infrastructure, preferably using dedicated test teams. Any testing for cross-team vulnerabilities should be conducted using dedicated teams created and owned by the researcher.\n\n##Conduct Guidelines\n\n\nWhile we encourage you to discover and report any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited and will result in disqualification from the Bug Bounty Program. By submitting a report to this program you agree to adhere to these guidelines. \n\n\n* Disclosing any vulnerabilities or suspected vulnerabilities you discover to any other person without explicit Salesforce authorization\n* Disclosing the contents of any submission to this program without explicit Slack authorization\n* Accessing private information of any person stored on a Slack product or service – You must use test accounts\n* Accessing sensitive information (e.g. credentials)\n* Performing actions that may negatively affect Salesforce system performance or its users (e.g. Spam, Phishing, Brute force, Distributed Denial of Service (DDoS))\n* Conducting any kind of physical attack on Slack personnel, property or data centers\n* Social engineering any Slack employee or contractor\n* Conducting vulnerability testing of participating services using anything other than test accounts (e.g. Developer or Trial Edition instances)\n* Exfiltrating data. Please test only the minimum necessary to validate a vulnerability (we can verify if data exfiltration would be possible from a vulnerability, and will reward with the impact in mind)\n* Violating any laws or breaching any agreements in order to discover vulnerabilities\n\nIf you are testing a publicly viewable area of Slack, please remove any test posts or accounts when you are done and refrain from engaging with actual users.\n\n##Disclosure Guidelines\n \nAs of August 15th, 2025, all Disclosure via HackerOne is paused for Slack. Researchers should expect all open and future requests for Mutual Disclosure to be closed until further notice. We will be taking this opportunity to align with our Salesforce bug bounty partners and provide a better experience for our researchers. There are no changes to the requirements for external disclosure outside of HackerOne.\n\nPublic disclosure of any submission to this program outside of the HackerOne platform (e.g. blogs, conference talks, research papers) requires explicit Slack approval regardless of the report status. Any form of public disclosure without explicit approval is considered a violation of our Conduct Guidelines. Please use the request disclosure option and specify that you are requesting to disclose externally. \n\n\n##Our Commitment to Researchers\n\n\nIf you submit a vulnerability report, the Slack security team and associated development organizations will use reasonable efforts to:\n\n\n\n* Respond in a timely manner, acknowledging receipt of your vulnerability report.\n* Investigate and consider your vulnerability report for eligibility under our Bug Bounty Program within 30 days of submission or less.\n* Notify you when the remediation or other action regarding the vulnerability has been implemented. \n\nSlack Products/Services In Scope for HackerOne Security Researchers\n\nThe Bug Bounty Program is limited to Slack products as specified within the *scope* section in HackerOne.\n\n\n\n##Qualifying Vulnerabilities \u0026 Bounties (In Scope)\n\n\nThe decision to grant a reward for a vulnerability report, and the value of a reward (if any), is entirely within Salesforce’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the *impact and severity* of the reported vulnerability. \n\n\n* You will qualify for consideration for a reward only if you are the first person to responsibly disclose an unknown vulnerability to us in accordance with these policies. The determination of whether you are the first person is solely within our responsibility. Vulnerabilities must also be relevant, exploitable, and well-documented in the vulnerability report. We are more likely to grant a reward if the vulnerability is specific, fixable and not currently exploited against us or our customers. \n\nThe following table lists our target reward range for different types of vulnerabilities within the published scope. All other vulnerabilities not on this table will also be considered and awarded a bounty on a case by case basis. Additional bounty may be awarded on top of these base amounts, as determined by the Bug Bounty management team.\n\n###The bounty values provided are subject to change at any time as determined by Salesforce.\n\n|Vulnerability Type | Critical | High | Medium | Low |\n| --- | --- | --- | --- | --- |\n|Authentication Bypass (Cross Org) |\t$10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Authentication Bypass (Same Org) |\t$9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Authorization Bypass / Privilege Escalation (Cross Org) |\t$10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Authorization Bypass / Privilege Escalation (Same Org) | $9,000 | $6,000 | $1,500 | $500 |\n|Circumvention of our Platform’s Permission Model (Cross Org) | $10,000 |\t$7,000 |\t$2,000 |$500 |\n|Circumvention of our Platform’s Permission Model (Same Org) |\t$9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Configuration/Stats//Log File Exposure |\t$5,000 |\t$2,500 |\t$1,000 |\t$250 |\n|CRLF injection/HTTP response splitting |\t$4,000 |\t$2,500 |\t$1,000 |\t$500 |\n|Cross Site Request Forgery (CSRF) |\tN/A | $2,500 | $1,000 | $250 |\n|Cross-Site Scripting (excluding self-XSS) | $5,000 | $3,500 | $1,000 | $250 |\n|Denial of Service | $7,000 |\t$4,000 |\t$1,000 |\t$500 |\n|Disclosure of Credit Card data |\t$14,000 |\t$11,000 |\t$6,000 |\t$500 |\n|Disclosure of Personal Identifiable Information |\t$500 |\t$500 |\t$500 |\t$500 |\n|DNS Hijacking / Subdomain Takeover | $5,000 |\t$2,500 |\t$500 |\t$250 |\n|Documentation Bug | N/A |\tN/A |\tN/A |\t$250 |\n|Excessive Agency |\t$12,000 |\t$9,000 |\t$5,000 |\t$500 |\n|Improper Access Control (Cross Org) |\t$10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Improper Access Control (Same Org) |\t$9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Insecure Direct Object Reference (IDOR) (Cross Org) | $10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Insecure Direct Object Reference (IDOR) (Same Org) | $9,000 | $6,000 |\t$1,500 |\t$500 |\n|Insecure Redirect |\tN/A |\tN/A | $1,000 |\t$250 |\n|Insufficiently Protected Credentials / Credential Exposure |\t$5,000 |\t$2,500 |\t$1,000 |\t$250 |\n|Model Theft |\t$12,000 |\t$9,000 |\t$5,000 |\t$500 |\n|Non-XXE SSRF |\t$5,000 |\t$3,500 |\t$1,500 |\t$500 |\n|Other Information Disclosure |\t$5,000 |\t$2,500 |\t$1,000 |\t$250 |\n|Other Injection (SOQL, Command Injection, RFI, LFI, etc.) | $9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Prompt Injection |\t$20,000 |\t$15,000 |\t$5,000 |\t$500 |\n|Remote Code Execution |\t$17,000 |\t$13,000 | $8,000 |\t$500 |\n|Salesforce-Owned/Controlled Misconfiguration and/or Custom APEX Vulnerabilities | $5,000 |\t$2,500 |\t$1,000 |\t$500 |\n|SQL Injection | $12,000 |\t$9,000 |\t$5,000 |\t$500 |\n|Unrestricted XXE / File System Access |\t$10,500 |\t$7,000 |\t$4,500 |\t$500 |\n\n##Vulnerability Severity Definitions\n\nThe following vulnerability severity definitions are based on internal Salesforce documentation. These definitions are a work in progress. The goal of adding these definitions to our policy is to: \n\n* Allow more efficient report triage\n* Align directly with internal Salesforce vulnerability ranking definitions\n* Remove ambiguity and subjective assignment of severity\n* Promote fair bounty payments\n* Promote researcher satisfaction\n\nIf you have feedback and/or suggestions to help us make these more clear and useful, please email your ideas to bugbountymanager@salesforce.com\n\n###Critical\n\n* Indicators of a ‘Critical’ severity level include but are not limited to vulnerabilities that:\n    * can affect a customer-facing or Slack production asset, or a non-production environment containing production customer data. Such an impact could be the compromise of the confidentiality, integrity of availability of such an asset or data.\n    * can result in compromise of sensitive systems or customer data without user interaction.\n    * can be exploited externally / via an untrusted network.\n    * can be remotely exploited with minimal knowledge, skill, or complexity.\n    * results in a root-level compromise of servers or infrastructure devices when exploited.\n    * have a CVSS or VPR score of 9.0 or greater.\n* Examples include, but are not limited to:\n    * External Remote Code Execution (RCE): Executing potentially harmful code on a server from outside the network that may result in system compromise and possible data exfiltration, depending on the specific implementation and context.\n    * Critical Data Exposure (Single/Cross-Tenant): Potential unauthorized disclosure of sensitive data that could affect one or multiple customers, with impact varying based on data sensitivity and scope of exposure.\n    * Arbitrary Account Takeover: Potentially gaining significant control of user accounts without proper authorization, where the impact depends on the account type and associated permissions.\n    * Privilege Escalation to Root/Admin: Possible elevation of privileges to higher levels on a system that could lead to varying degrees of control over the affected system or infrastructure.\n    * Exploitation of Publicly Known and Actively Exploited Vulnerabilities: Potentially leveraging known flaws that may be under active attack, where impact varies based on the vulnerability context. The Public Disclosure must be older than 30 days if the risk is Critical.\n    * External Logic Flaws Causing Significant Service Disruption: Possible abuse of application logic accessible externally that might cause service disruptions, with impact varying based on affected business functions and duration.\n\n\n###High\n\n* Indicators of a ‘High’ severity level include but are not limited to vulnerabilities that:\n    * can affect production or customer-facing assets, or non-production environments with sensitive data.\n    * allow unauthorized access or modification of sensitive data or elevated privileges, but require more skill or context than Critical vulnerabilities.\n    * allow local users to gain increased privileges.\n    * result in susceptibility to an external, simply executed, single actor, logic-based attacks resulting in significant performance degradation of one or more critical systems/products.\n    * Can be exploited with moderate technical knowledge or skill, and is likely to result in system compromise or denial of service. Example: A publicly available exploit without evidence of active exploitation, or a proof-of-concept exploit.\n    * Have a CVSS or VPR score between 7.0 and 8.9\n* Examples include, but are not limited to:\n    * Privilege Escalation (Limited Scope): Gaining higher access within the application allowing unauthorized access to sensitive data and functionalities.\n    * External Persistent/Stored Cross-Site Scripting (XSS): Permanently injecting malicious scripts into a website, affecting other users potentially leading to session hijacking or defacement.\n    * External Cross-Site Request Forgery (CSRF) on Sensitive Functions: Forcing a user to perform unwanted actions on a web application leading to unauthorized state changes or data manipulation.\n    * External Exposure of Sensitive Information via Stack Traces: Revealing internal application details in error messages potentially leading to sensitive information leakage.\n    * Internal Use of Weak Cryptography (Practically Exploitable): Using breakable encryption within the internal network potentially leading to confidential data disclosure.\n    * Internal Remote Arbitrary Code Execution (Without Mitigating Circumstances): Executing code on an internal server potentially leading to system compromise or partial service disruption.\n    * Internal Command or SQL Injection (Without Mitigating Circumstances): Injecting malicious commands into an internal system or database allowing unauthorized data access/modification/deletion.\n    * Internal Exposure of Sensitive Information: Unauthorized access to data by internal users potentially leading to data breach or privacy violations.\n    * Internal Use of Default or Weak Credentials: Using easily guessed passwords for internal systems allowing unauthorized system access.\n    * Susceptibility to Publicly Disclosed Vulnerabilities (High Impact): Using software with known, dangerous flaws potentially leading to system compromise or data loss.\n    * External Path Traversal: Accessing restricted files or directories on the server from the outside potentially leading to access to sensitive files or code execution.\n    * Server-Side Request Forgery (SSRF): Forcing the server to make requests to unintended locations potentially leading to access to internal services or data exfiltration.\n    * Unrestricted File Upload (High Risk): Uploading files without proper security checks potentially leading to remote code execution or defacement.\n    * XML External Entity (XXE) Injection: Exploiting vulnerabilities in XML processing potentially leading to confidential data disclosure or remote code execution.\n\n\n###Medium\n\n* Indicators of a ‘Medium’ severity level include but are not limited to vulnerabilities that:\n    * may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances.  Such a difficulty could require significant knowledge or skill to exploit, or there may be controls in place to prevent exploitation.\n    * could have had a critical or high impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.\n    * require significant user interaction or chaining with other bugs to escalate impact.\n    * result in susceptibility to external, simply executed, single actor, logic-based attacks resulting in some measurable performance degradation of one or more critical systems/products.\n    * may involve low-sensitivity data or present a limited attack surface.\n    * have a CVSS or VPR score between 4.0 and 6.9.\n* Examples include, but are not limited to:\n    * External Unintended Internal Information Disclosure: Revealing internal details to external users potentially aiding further attacks.\n    * Internal Network/Application Cross-Site Scripting (XSS): Injecting malicious scripts into an internal web application potentially allowing attackers to hijack user sessions or deface internal applications.\n    * Internal Network/Application Cross-Site Request Forgery (CSRF): Forcing an authenticated internal user to perform unwanted actions potentially leading to unauthorized actions on internal applications.\n    * Internal Use of Weak Cryptography (Practically Exploitable by Sophisticated Actors): Using breakable encryption within the internal network potentially allowing sensitive internal data decryption.\n    * Usage of End-of-Life (EoL) Operating Systems or Software (Internal): Running unsupported software on internal systems increasing susceptibility to known vulnerabilities.\n    * External Facing Content Spoofing: Manipulating content to deceive users potentially leading to phishing or reputational damage.\n    * Cleartext Transmission of Sensitive Internal Data: Sending unencrypted sensitive data within the internal network potentially allowing interception of confidential internal data.\n    * Predictable Session Identifiers (Internal): Using easily guessable session tokens within the internal network potentially allowing attackers to hijack legitimate user sessions.\n    * Denial-of-Service (DoS) via Logic Flaws (Single Actor, Simple Execution, Measurable Performance Degradation): Causing a noticeable slowdown or temporary unavailability of a service with minimal effort.\n    * Path Traversal on Internal Resources: Accessing restricted files or directories within the internal network potentially allowing unauthorized access to sensitive internal configuration files or data.\n    * Missing or Ineffective Rate Limiting on Non-Critical Internal Endpoints: Failing to limit requests to certain internal features potentially leading to resource exhaustion. While researchers should always feel free to report discoveries to our program, we will only accept and pay for valid Medium severity issues related to CVEs 6 months past publish date.\n\n###Low\n\n* Indicators of a ‘Low’ severity level includes but is not limited to vulnerabilities that:\n    * do not expose sensitive data or infrastructure.\n    * represent best practice gaps, low-impact misconfigurations, or non-exploitable flaws.\n    * may be more difficult to exploit but could lead to minimal compromise of the confidentiality, integrity, or availability of resources under unlikely circumstances.\n    * require unlikely circumstances to be able to be exploited, or where a successful exploit would have minimal consequences.\n    * require complex prerequisites or attacker access to internal environments.\n    * results in susceptibility to external, simply executed, single actor, logic-based attacks resulting in minor performance degradation of one or more critical systems/products.\n    * have a CVSS or VPR score less than 4.0.\n* Examples include, but are not limited to:\n    * Cross-Site Scripting (XSS) from an Authenticated Customer Admin: Injecting malicious scripts through an admin account potentially leading to minor data theft or defacement within admin scope.\n    * Exposure of Internal Default Pages (e.g., Apache server-status): Revealing server information through standard configuration pages potentially aiding reconnaissance.\n    * Exposure of Server Configuration Information: Leaking details about the server setup slightly increasing attack surface knowledge.\n    * Use of Weak Cryptography Not Practically Exploitable: Using breakable encryption with mitigating factors presenting negligible real-world risk.\n    * External Cross-Site Request Forgery (CSRF) on Non-Sensitive Functions: Forcing a user to perform unimportant actions on a website potentially leading to unwanted minor actions.\n    * Documentation Bugs Revealing Sensitive but Outdated Information: Documentation inaccuracies that, from a security perspective, misrepresent product behavior, including instances where outdated information could reveal sensitive configurations and cause confusion.\n    * HTTP Public Key Pinning (HPKP) Configuration Errors with Fallback: Misconfiguration of certificate pinning with a working backup indicating a configuration issue.\n    * Verbose Error Messages Revealing Non-Sensitive Information: Detailed error outputs exposing internal application structure or non-critical data. The data exposed must be, at some point, important from a security perspective.\n    * Absence of Rate Limiting on Non-Authentication Related, Low-Impact Features: Lack of request limits on unimportant features potentially leading to minor resource exhaustion.\n    * Information Disclosure Through Non-Standard HTTP Headers: Revealing minor information in HTTP headers slightly increasing knowledge for attackers.\n\n\n##Qualifying Vulnerability Descriptions\n\n\n| Category | Description |\n| --- | --- |\n| Remote Code Execution | CWE-94: AKA \"Arbitrary Code Execution\".  Describes a security bug that allows an attacker to execute arbitrary commands or code on a target machine or in a target process. The exploit PoC may include many other vulnerability types, but ultimately the result is p0wnage of the server(s) and/or environment.  [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Disclosure of Credit Card data | CWE-359:  This is self-explanatory. Any security bug which allows disclosure of credit card information to an unauthorized user or system qualifies as Disclosure of Credit Card Data |\n| SQL Injection | CWE-1027:  SQL injection is a code injection technique in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Unrestricted XXE / File System Access | CWE-611:  External XML Entity Injection (XXE) is a specific type of Server Side Request Forgery(SSRF) which affects an XML processing engine server-side on a target. Specifically, blind XXE is when the results are either error-based or cause 3rd party interaction with services such as HTTP, FTP \u0026 DNS. An XXE attack typically occurs when XML input containing a reference to an external entity is processed by a weakly configured parser. An attacker can leverage an XXE attack to access sensitive data and read local or remote files. In a similar manner to SSRF, an attacker could introduce malicious code through Remote Code Execution (RCE).  [scr: https://blog.zsec.uk/out-of-band-xxe-2/]  [src: https://chris-young.net/2018/04/13/xxe-xml-external-entity/] |\n| Significant Authentication Bypass | CWE-305:  Authentication bypass is a vulnerability that allows an attacker access to credential protected resources without first acquiring valid credentials. Examples of this vulnerability include:* SQL injection during login to bypasses credential authentication* Direct access to resources normally beyond an authentication mechanism, such as a login screen, which do not independently validate the users authenticated session.* Failure to enumerate and enforce the systems' access policy. * A weak authentication system that allows a valid identity to be forged. | \n| Significant Authorization Bypass | CWE-285:  Authorization is the concept of allowing access to resources only to those permitted to use them. Vulnerabilities that bypass authorization checks may allow access to protected resources beyond what was intended by the system. Examples of authorization bypass include Insecure Direct Object Reference and Session Token Alteration. In each of these examples, the system trusts the users' requests because of improper or insecure implementation. |\n| Cross Instance Privilege Escalation | Salesforce is a multi-tenant platform in which \"instances\" are created for each Org. A cross-instance privilege escalation involves some user in instance A having access to data in instance B without proper authorization. |\n| Denial of Service | Susceptibility to an external, simply executed, single actor, logic-based attack resulting in a service outage or significant performance degradation of one or more critical systems/products  |\n| Disclosure of Personal Identifiable Information | CWE-200:  Personally identifiable information, or PII, is any data that could potentially be used to identify a particular person. As it relates to Salesforce, PII Disclosure bugs involve PII data stored within any in-scope platforms, excluding Salesforce Employee data such as Name and Contact information.  [src: https://www.lifelock.com/learn-identity-theft-resources-what-is-personally-identifiable-information.html] |\n| Salesforce Platform Misconfiguration and/or Custom APEX Vulnerabilities (Salesforce Owned/Controlled) | The Salesforce Platform is highly configurable, customizable, and supports custom code in the form of APEX code, Visualforce pages, etc. It is therefore capable of being misconfigured in such a way as to leak information or to otherwise be insecure. This category of vulnerability is specific to Salesforce owned and operated sites, NOT Salesforce customer-owned and operated Salesforce instances. If you identify a configuration vulnerability in a customer site please report it to that company via their Bug Bounty program or their security@\u003csome company dot com\u003e email address. There is no guarantee that the customer will respond to your email or bug submission, and it is out of Salesforce control. Please do not expect Salesforce to handle reports of customer misconfiguration.|\n| Privilege Escalation / Improper Access Control | Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in a software application to gain elevated access to resources that are normally protected from an application or user. The result is that a user with more privileges than intended by the application developer or system administrator can perform unauthorized actions. Note that Privilege Escalation is different from Permission Model Circumvention in that PE involves accessing functionality beyond that assigned to a given role, or somehow adding resource permissions to a given role without authorization, while PMC involves a complete bypass of security controls meant to enforce permissions. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access.  [src: https://en.wikipedia.org/wiki/Privilege_escalation] |\n| Non-XXE SSRF | In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.[src:https://www.owasp.org/index.php/Server_Side_Request_Forgery] |\n| Insecure Direct Object Reference | IDOR occurs when unvalidated user-supplied input is submitted and direct access to the object requested is provided. Vulnerability reports for IDOR are valid when the result is unauthorized information disclosure, modification or destruction of data, or performing a function outside of the limits of the current user. |\n| CRLF injection/HTTP response splitting  | HTTP response splitting occurs when data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. [src: https://www.owasp.org/index.php/HTTP_Response_Splitting] |\n| Circumvention of our Platform’s Permission Model | Permission Model Circumvention involves a complete bypass of security controls meant to enforce permissions. An example of PMC involves an insecurely configured system in which an API gateway fronts for several servers and implements authentication/authorization. The configuration is such that the URI to the backend servers can be identified and they are directly accessible without any additional authentication or authorization checks..While there is an authX model in place, it was trivially circumventable. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access. |\n| Cross-Site Scripting (excluding self-XSS) | CWE-80:  Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. [src:https://en.wikipedia.org/wiki/Cross-site_scripting] |\n| Cross-Site Request Forgery (CSRF) on critical actions | CWE-352:  Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.  [src: https://en.wikipedia.org/wiki/Cross-site_request_forgery] |\n| Insufficiently Protected Credentials / Credential Exposure | CWE-522:  CWE-522: Within the context of the Salesforce/HackerOne Bug Bounty program, credential exposure involves finding, or gaining access to a user or system credentials which are not meant to be public. An example of IPC would be finding a Github or other repo containing configuration files that contain usernames, passwords, API keys, private keys, etc. Another example is an exposure of a single user's credentials on the querystring, in cookies, or in other HTTP headers. |\n| Insecure/Open Redirect | CWE-601:  An HTTP parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. |\n| DNS Hijacking / Subdomain Takeover | DNS hijacking or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries.The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.  [src: https://en.wikipedia.org/wiki/DNS_hijacking] [src: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers] |\n| Configuration/Stats//Log File Exposure | CWE-532 Information Exposure Through Log Files. CWE-200: Information Exposure. Any instance in which log files or server/application configuration files are accessible when they are not meant to be. |\n| Documentation Bug | Any instance in which, from a strictly security-based perspective, the published documentation is incorrect with regard to the behavior of the product. | \n\n\n##Non-Qualifying Vulnerabilities (Out of Scope)\n\n\nThe following types of issues are *specifically excluded* from our Bug Bounty Program:\n\n- Attacks requiring physical access to a user's unlocked device\n- Reports of spam, phishing or security best practices\n- Bugs categorized as P3 (low risk)\n- Clickjacking and issues only exploitable through clickjacking\n* CSRF-able actions that do not require authentication (or a session) to exploit or CSRF issues which have no security impact to Slack.\n* HTML and Link injections\n* Issues related to \"Editable Github Wiki Pages\"\n* Issues related to Salesforce *Partner* User Credential Disclosure in public code repositories such as GitHub. *Please note that this type of activity is explicitly excluded by the Conduct Guidelines in this policy.*\n* TOCTOU bugs involving platform permission changes. For example; User A has an active session, Admin reduces or increases permissions for User A, User A permissions do not change until User A logs out and back in. This is currently WAD on Salesforce platforms.\n* Invalid links from any Salesforce site to any social media site in which a claim of \"account takeover\" or \"possible phishing attacks\" are the basis for the report.\n* Bugs in content/services that are not owned/operated by Salesforce\n* Vulnerabilities affecting users of outdated or unsupported browsers or platforms\n* Vulnerabilities that have already been addressed in a product update regardless of whether the update has been applied to the publicly available research machines\n* Subdomain takeovers for out of scope domains\n* Self-XSS or XSS bugs requiring an unlikely amount of user interaction\n* XSS in our content sandbox under .content.force.com (http://content.force.com/)\n- XSS under \\.sitepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.livepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.visual.force.com (with the exception of Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n* XSS in custom apps under .force.com (with the exception of lightning.force.com and Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n- Descriptive error messages (e.g. Stack Traces, application or server errors)\n- HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n- Fingerprinting / banner disclosure on common/public services.\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Scripting or other automation and brute-forcing of intended functionality\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n- Lack of Secure and HTTPOnly cookie flags\n- Content spoofing (text injection) or IDN homograph attacks\n- Tabnabbing \n- Email configuration issues (SPF, DKIM, DMARC)\n- Weak Captcha / Captcha Bypass\n- Forced Login / Logout CSRF\n- Account lockout, Login or Forgot Password page brute force\n- Password complexity or account recovery policies\n- Username / email enumeration (brute force)\n- HTTPS Mixed Content\n- Missing HTTP security headers, specifically: Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy.\n- OPTIONS HTTP method enabled\n- Known SSL issues (e.g. attacks such as BEAST, BREACH, POODLE, TLS Renegotiation)\n- SSL Forward Secrecy or HSTS not enabled\n- Weak SSL/TLS Cipher Suites\n- CSV Excel Formula injection\n- Issues related to networking protocols or industry standards not controlled by Salesforce\n- Sending vulnerability reports using automated tools without validation\n- Use of a known-vulnerable library without evidence of exploitability\n- Reflected XSS involving Adobe Flash files (.swf)\n\n*If you are unsure whether a bug or issue that you discover in a participating service is a non-qualifying vulnerability, please email us at \u003cbugbountymanager@salesforce.com\u003e*\n\n\n_Intellectual Property_\n\n\nParticipating in the Bug Bounty Program does not grant to you or any other third party any rights to any Slack or Salesforce intellectual property, product or service. All rights not otherwise granted herein are expressly reserved. Whether or not we grant you a reward, you hereby assign to Salesforce all right, title and interest (including all intellectual property rights), in the contents of all vulnerability reports that you submit to Salesforce. \n\nBy participating in the Bug Bounty Program, you represent that you have the right to assign all such right, title and interest to us and that your participation in the Bug Bounty Program and assignment of such right, title and interest will not breach any agreement you may have with a third party (e.g. your employer).\n\n\n_Other Terms and Conditions_\n\n\nSalesforce pledges not to pursue a civil action or initiate a complaint to law enforcement against researchers for security research and vulnerability disclosure activities conducted in accordance with this Policy. We consider security research and vulnerability disclosure activities conducted in accordance with this Policy “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA and applicable anti-hacking laws such as Cal. Penal Code 502(c). We waive any DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy.\n\nBy participating in the Bug Bounty Program, you agree to be bound by these rules. These policies will apply to you in addition to, and will not replace, any other terms and conditions that are imposed by HackerOne.\n\n- Your participation in the Bug Bounty Program does not create any kind of employment relationship or partnership between you and Salesforce. You must not hold yourself out as a Salesforce employee or as someone in any way affiliated with Salesforce.\n- You must comply with all applicable laws in connection with your participation in this program. \n- You are responsible for any applicable taxes associated with any reward you receive. \n- Vulnerability reports received prior to the Bug Bounty Program launch are not eligible for rewards and may not be re-submitted for a reward.\n- You will not use any of our trademarks, service marks and logos.\n- We may modify this Policy at any time by posting an updated version of this document.\n- We may terminate this Bug Bounty Program at any time without notice. \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":"2025-08-15T15:48:16.340Z"},{"id":3761204,"new_policy":"## Slack Technologies, LLC, a Salesforce company\n\nOver _$12M_ in bounties awarded across all our H1 Bug Bounty programs since 2015!\n\n\nAt Slack, a Salesforce company, Trust is our #1 value and we take the protection of our customers' data very seriously. As a result, we encourage responsible reporting and disclosure of any vulnerabilities that may be found on our websites, APIs, or applications. \n\nSlack is committed to working with security researchers to verify and address any potential vulnerabilities that are reported to us. If you want to help us make our products safer with the possibility of a reward in the process, you are in the right place!\n\nPlease review these terms before you test and/or report a vulnerability. Slack pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.\n\n##Eligibility for the Bug Bounty Program\n\nUnder our Bug Bounty Program, qualified individuals are encouraged to submit bug reports that detail existing vulnerabilities in certain in-scope Salesforce products and services. In certain circumstances, Salesforce may grant monetary rewards to those who submit vulnerability reports.\n\nWe are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Slack. However, only those researchers that meet the following criteria may be eligible to receive a reward. Some of the requirements to participate in the Bug Bounty Program include:\n\n\n* You must be the first reporter of a vulnerability associated with a participating service (we will also not reward for a known vulnerability which we are actively fixing)\n* You must have personally discovered the vulnerability and you may not report a vulnerability that was discovered by another person (including, and especially, someone who does not qualify to participate in the Bug Bounty Program)\n* You must not be employed by Slack, Salesforce, its subsidiaries, or any related entities, currently or in the last 12 months.\n* You must comply with this Policy when discovering the vulnerability and submitting the vulnerability report\n* Slack or H1 can’t be legally prohibited from rewarding you for any reason\n* Non-automated testing is allowed on production Slack infrastructure, preferably using dedicated test teams. Any testing for cross-team vulnerabilities should be conducted using dedicated teams created and owned by the researcher.\n\n##Conduct Guidelines\n\n\nWhile we encourage you to discover and report to us any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited and will result in disqualification from the Bug Bounty Program:\n\n\n* Disclosing any vulnerabilities or suspected vulnerabilities you discover to any other person without explicit Salesforce authorization\n* Disclosing the contents of any submission to our program without explicit Slack authorization\n* Accessing private information of any person stored on a Slack product or service – You must use test accounts\n* Accessing sensitive information (e.g., credentials)\n* Performing actions that may negatively affect Salesforce system performance or its users (e.g. Spam, Phishing, Brute force, Distributed Denial of Service (DDoS))\n* Conducting any kind of physical attack on Slack personnel, property or data centers\n* Social engineering any Slack employee or contractor\n* Conducting vulnerability testing of participating services using anything other than test accounts (e.g. Developer or Trial Edition instances)\n* Exfiltrating data. Please test only the minimum necessary to validate a vulnerability (we can verify if data exfiltration would be possible from a vulnerability, and will reward with the impact in mind)\n* Violating any laws or breaching any agreements in order to discover vulnerabilities\n\nIf you are testing a publicly viewable area of Slack, please remove any test posts or accounts when you are done and refrain from engaging with actual users.\n\n\n##Our Commitment to Researchers\n\n\nIf you submit a vulnerability report, the Slack security team and associated development organizations will use reasonable efforts to:\n\n\n\n* Respond in a timely manner, acknowledging receipt of your vulnerability report.\n* Investigate and consider your vulnerability report for eligibility under our Bug Bounty Program within 30 days of submission or less.\n* Notify you when the remediation or other action regarding the vulnerability has been implemented. \n\nSlack Products/Services In Scope for H1 Security Researchers\n\nThe Bug Bounty Program is limited to Slack products as specified within the *scope* section in HackerOne.\n\n\n\n##Qualifying Vulnerabilities \u0026 Bounties (In Scope)\n\n\nThe decision to grant a reward for a vulnerability report, and the value of a reward (if any), is entirely within Salesforce’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the *impact and severity* of the reported vulnerability. \n\n\n* You will qualify for consideration for a reward only if you are the first person to responsibly disclose an unknown vulnerability to us in accordance with these policies. The determination of whether you are the first person is solely within our responsibility. Vulnerabilities must also be relevant, exploitable, and well-documented in the vulnerability report. We are more likely to grant a reward if the vulnerability is specific, fixable and not currently exploited against us or our customers. \n\nThe following table lists our target reward range for different types of vulnerabilities within the published scope. All other vulnerabilities not on this table will also be considered and awarded a bounty on a case by case basis. Additional bounty may be awarded on top of these base amounts, as determined by the Bug Bounty management team.\n\n###The bounty values provided are subject to change at any time as determined by Salesforce.\n\n|Vulnerability Type | Critical | High | Medium | Low |\n| --- | --- | --- | --- | --- |\n|Authentication Bypass (Cross Org) |\t$10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Authentication Bypass (Same Org) |\t$9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Authorization Bypass / Privilege Escalation (Cross Org) |\t$10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Authorization Bypass / Privilege Escalation (Same Org) | $9,000 | $6,000 | $1,500 | $500 |\n|Circumvention of our Platform’s Permission Model (Cross Org) | $10,000 |\t$7,000 |\t$2,000 |$500 |\n|Circumvention of our Platform’s Permission Model (Same Org) |\t$9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Configuration/Stats//Log File Exposure |\t$5,000 |\t$2,500 |\t$1,000 |\t$250 |\n|CRLF injection/HTTP response splitting |\t$4,000 |\t$2,500 |\t$1,000 |\t$500 |\n|Cross Site Request Forgery (CSRF) |\tN/A | $2,500 | $1,000 | $250 |\n|Cross-Site Scripting (excluding self-XSS) | $5,000 | $3,500 | $1,000 | $250 |\n|Denial of Service | $7,000 |\t$4,000 |\t$1,000 |\t$500 |\n|Disclosure of Credit Card data |\t$14,000 |\t$11,000 |\t$6,000 |\t$500 |\n|Disclosure of Personal Identifiable Information |\t$500 |\t$500 |\t$500 |\t$500 |\n|DNS Hijacking / Subdomain Takeover | $5,000 |\t$2,500 |\t$500 |\t$250 |\n|Documentation Bug | N/A |\tN/A |\tN/A |\t$250 |\n|Excessive Agency |\t$12,000 |\t$9,000 |\t$5,000 |\t$500 |\n|Improper Access Control (Cross Org) |\t$10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Improper Access Control (Same Org) |\t$9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Insecure Direct Object Reference (IDOR) (Cross Org) | $10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Insecure Direct Object Reference (IDOR) (Same Org) | $9,000 | $6,000 |\t$1,500 |\t$500 |\n|Insecure Redirect |\tN/A |\tN/A | $1,000 |\t$250 |\n|Insufficiently Protected Credentials / Credential Exposure |\t$5,000 |\t$2,500 |\t$1,000 |\t$250 |\n|Model Theft |\t$12,000 |\t$9,000 |\t$5,000 |\t$500 |\n|Non-XXE SSRF |\t$5,000 |\t$3,500 |\t$1,500 |\t$500 |\n|Other Information Disclosure |\t$5,000 |\t$2,500 |\t$1,000 |\t$250 |\n|Other Injection (SOQL, Command Injection, RFI, LFI, etc.) | $9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Prompt Injection |\t$20,000 |\t$15,000 |\t$5,000 |\t$500 |\n|Remote Code Execution |\t$17,000 |\t$13,000 | $8,000 |\t$500 |\n|Salesforce-Owned/Controlled Misconfiguration and/or Custom APEX Vulnerabilities | $5,000 |\t$2,500 |\t$1,000 |\t$500 |\n|SQL Injection | $12,000 |\t$9,000 |\t$5,000 |\t$500 |\n|Unrestricted XXE / File System Access |\t$10,500 |\t$7,000 |\t$4,500 |\t$500 |\n\n##Vulnerability Severity Definitions\n\nThe following vulnerability severity definitions are based on internal Salesforce documentation. These definitions are a work in progress. The goal of adding these definitions to our policy is to: \n\n* Allow more efficient report triage\n* Align directly with internal Salesforce vulnerability ranking definitions\n* Remove ambiguity and subjective assignment of severity\n* Promote fair bounty payments\n* Promote researcher satisfaction\n\nIf you have feedback and/or suggestions to help us make these more clear and useful, please email your ideas to bugbountymanager@salesforce.com\n\n###Critical\n\n* Indicators of a ‘Critical’ severity level include but are not limited to vulnerabilities that:\n    * can affect a customer-facing or Slack production asset, or a non-production environment containing production customer data. Such an impact could be the compromise of the confidentiality, integrity of availability of such an asset or data.\n    * can result in compromise of sensitive systems or customer data without user interaction.\n    * can be exploited externally / via an untrusted network.\n    * can be remotely exploited with minimal knowledge, skill, or complexity.\n    * results in a root-level compromise of servers or infrastructure devices when exploited.\n    * have a CVSS or VPR score of 9.0 or greater.\n* Examples include, but are not limited to:\n    * External Remote Code Execution (RCE): Executing potentially harmful code on a server from outside the network that may result in system compromise and possible data exfiltration, depending on the specific implementation and context.\n    * Critical Data Exposure (Single/Cross-Tenant): Potential unauthorized disclosure of sensitive data that could affect one or multiple customers, with impact varying based on data sensitivity and scope of exposure.\n    * Arbitrary Account Takeover: Potentially gaining significant control of user accounts without proper authorization, where the impact depends on the account type and associated permissions.\n    * Privilege Escalation to Root/Admin: Possible elevation of privileges to higher levels on a system that could lead to varying degrees of control over the affected system or infrastructure.\n    * Exploitation of Publicly Known and Actively Exploited Vulnerabilities: Potentially leveraging known flaws that may be under active attack, where impact varies based on the vulnerability context. The Public Disclosure must be older than 30 days if the risk is Critical.\n    * External Logic Flaws Causing Significant Service Disruption: Possible abuse of application logic accessible externally that might cause service disruptions, with impact varying based on affected business functions and duration.\n\n\n###High\n\n* Indicators of a ‘High’ severity level include but are not limited to vulnerabilities that:\n    * can affect production or customer-facing assets, or non-production environments with sensitive data.\n    * allow unauthorized access or modification of sensitive data or elevated privileges, but require more skill or context than Critical vulnerabilities.\n    * allow local users to gain increased privileges.\n    * result in susceptibility to an external, simply executed, single actor, logic-based attacks resulting in significant performance degradation of one or more critical systems/products.\n    * Can be exploited with moderate technical knowledge or skill, and is likely to result in system compromise or denial of service. Example: A publicly available exploit without evidence of active exploitation, or a proof-of-concept exploit.\n    * Have a CVSS or VPR score between 7.0 and 8.9\n* Examples include, but are not limited to:\n    * Privilege Escalation (Limited Scope): Gaining higher access within the application allowing unauthorized access to sensitive data and functionalities.\n    * External Persistent/Stored Cross-Site Scripting (XSS): Permanently injecting malicious scripts into a website, affecting other users potentially leading to session hijacking or defacement.\n    * External Cross-Site Request Forgery (CSRF) on Sensitive Functions: Forcing a user to perform unwanted actions on a web application leading to unauthorized state changes or data manipulation.\n    * External Exposure of Sensitive Information via Stack Traces: Revealing internal application details in error messages potentially leading to sensitive information leakage.\n    * Internal Use of Weak Cryptography (Practically Exploitable): Using breakable encryption within the internal network potentially leading to confidential data disclosure.\n    * Internal Remote Arbitrary Code Execution (Without Mitigating Circumstances): Executing code on an internal server potentially leading to system compromise or partial service disruption.\n    * Internal Command or SQL Injection (Without Mitigating Circumstances): Injecting malicious commands into an internal system or database allowing unauthorized data access/modification/deletion.\n    * Internal Exposure of Sensitive Information: Unauthorized access to data by internal users potentially leading to data breach or privacy violations.\n    * Internal Use of Default or Weak Credentials: Using easily guessed passwords for internal systems allowing unauthorized system access.\n    * Susceptibility to Publicly Disclosed Vulnerabilities (High Impact): Using software with known, dangerous flaws potentially leading to system compromise or data loss.\n    * External Path Traversal: Accessing restricted files or directories on the server from the outside potentially leading to access to sensitive files or code execution.\n    * Server-Side Request Forgery (SSRF): Forcing the server to make requests to unintended locations potentially leading to access to internal services or data exfiltration.\n    * Unrestricted File Upload (High Risk): Uploading files without proper security checks potentially leading to remote code execution or defacement.\n    * XML External Entity (XXE) Injection: Exploiting vulnerabilities in XML processing potentially leading to confidential data disclosure or remote code execution.\n\n\n###Medium\n\n* Indicators of a ‘Medium’ severity level include but are not limited to vulnerabilities that:\n    * may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances.  Such a difficulty could require significant knowledge or skill to exploit, or there may be controls in place to prevent exploitation.\n    * could have had a critical or high impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.\n    * require significant user interaction or chaining with other bugs to escalate impact.\n    * result in susceptibility to external, simply executed, single actor, logic-based attacks resulting in some measurable performance degradation of one or more critical systems/products.\n    * may involve low-sensitivity data or present a limited attack surface.\n    * have a CVSS or VPR score between 4.0 and 6.9.\n* Examples include, but are not limited to:\n    * External Unintended Internal Information Disclosure: Revealing internal details to external users potentially aiding further attacks.\n    * Internal Network/Application Cross-Site Scripting (XSS): Injecting malicious scripts into an internal web application potentially allowing attackers to hijack user sessions or deface internal applications.\n    * Internal Network/Application Cross-Site Request Forgery (CSRF): Forcing an authenticated internal user to perform unwanted actions potentially leading to unauthorized actions on internal applications.\n    * Internal Use of Weak Cryptography (Practically Exploitable by Sophisticated Actors): Using breakable encryption within the internal network potentially allowing sensitive internal data decryption.\n    * Usage of End-of-Life (EoL) Operating Systems or Software (Internal): Running unsupported software on internal systems increasing susceptibility to known vulnerabilities.\n    * External Facing Content Spoofing: Manipulating content to deceive users potentially leading to phishing or reputational damage.\n    * Cleartext Transmission of Sensitive Internal Data: Sending unencrypted sensitive data within the internal network potentially allowing interception of confidential internal data.\n    * Predictable Session Identifiers (Internal): Using easily guessable session tokens within the internal network potentially allowing attackers to hijack legitimate user sessions.\n    * Denial-of-Service (DoS) via Logic Flaws (Single Actor, Simple Execution, Measurable Performance Degradation): Causing a noticeable slowdown or temporary unavailability of a service with minimal effort.\n    * Path Traversal on Internal Resources: Accessing restricted files or directories within the internal network potentially allowing unauthorized access to sensitive internal configuration files or data.\n    * Missing or Ineffective Rate Limiting on Non-Critical Internal Endpoints: Failing to limit requests to certain internal features potentially leading to resource exhaustion. While researchers should always feel free to report discoveries to our program, we will only accept and pay for valid Medium severity issues related to CVEs 6 months past publish date.\n\n###Low\n\n* Indicators of a ‘Low’ severity level includes but is not limited to vulnerabilities that:\n    * do not expose sensitive data or infrastructure.\n    * represent best practice gaps, low-impact misconfigurations, or non-exploitable flaws.\n    * may be more difficult to exploit but could lead to minimal compromise of the confidentiality, integrity, or availability of resources under unlikely circumstances.\n    * require unlikely circumstances to be able to be exploited, or where a successful exploit would have minimal consequences.\n    * require complex prerequisites or attacker access to internal environments.\n    * results in susceptibility to external, simply executed, single actor, logic-based attacks resulting in minor performance degradation of one or more critical systems/products.\n    * have a CVSS or VPR score less than 4.0.\n* Examples include, but are not limited to:\n    * Cross-Site Scripting (XSS) from an Authenticated Customer Admin: Injecting malicious scripts through an admin account potentially leading to minor data theft or defacement within admin scope.\n    * Exposure of Internal Default Pages (e.g., Apache server-status): Revealing server information through standard configuration pages potentially aiding reconnaissance.\n    * Exposure of Server Configuration Information: Leaking details about the server setup slightly increasing attack surface knowledge.\n    * Use of Weak Cryptography Not Practically Exploitable: Using breakable encryption with mitigating factors presenting negligible real-world risk.\n    * External Cross-Site Request Forgery (CSRF) on Non-Sensitive Functions: Forcing a user to perform unimportant actions on a website potentially leading to unwanted minor actions.\n    * Documentation Bugs Revealing Sensitive but Outdated Information: Documentation inaccuracies that, from a security perspective, misrepresent product behavior, including instances where outdated information could reveal sensitive configurations and cause confusion.\n    * HTTP Public Key Pinning (HPKP) Configuration Errors with Fallback: Misconfiguration of certificate pinning with a working backup indicating a configuration issue.\n    * Verbose Error Messages Revealing Non-Sensitive Information: Detailed error outputs exposing internal application structure or non-critical data. The data exposed must be, at some point, important from a security perspective.\n    * Absence of Rate Limiting on Non-Authentication Related, Low-Impact Features: Lack of request limits on unimportant features potentially leading to minor resource exhaustion.\n    * Information Disclosure Through Non-Standard HTTP Headers: Revealing minor information in HTTP headers slightly increasing knowledge for attackers.\n\n\n##Qualifying Vulnerability Descriptions\n\n\n| Category | Description |\n| --- | --- |\n| Remote Code Execution | CWE-94: AKA \"Arbitrary Code Execution\".  Describes a security bug that allows an attacker to execute arbitrary commands or code on a target machine or in a target process. The exploit PoC may include many other vulnerability types, but ultimately the result is p0wnage of the server(s) and/or environment.  [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Disclosure of Credit Card data | CWE-359:  This is self-explanatory. Any security bug which allows disclosure of credit card information to an unauthorized user or system qualifies as Disclosure of Credit Card Data |\n| SQL Injection | CWE-1027:  SQL injection is a code injection technique in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Unrestricted XXE / File System Access | CWE-611:  External XML Entity Injection (XXE) is a specific type of Server Side Request Forgery(SSRF) which affects an XML processing engine server-side on a target. Specifically, blind XXE is when the results are either error-based or cause 3rd party interaction with services such as HTTP, FTP \u0026 DNS. An XXE attack typically occurs when XML input containing a reference to an external entity is processed by a weakly configured parser. An attacker can leverage an XXE attack to access sensitive data and read local or remote files. In a similar manner to SSRF, an attacker could introduce malicious code through Remote Code Execution (RCE).  [scr: https://blog.zsec.uk/out-of-band-xxe-2/]  [src: https://chris-young.net/2018/04/13/xxe-xml-external-entity/] |\n| Significant Authentication Bypass | CWE-305:  Authentication bypass is a vulnerability that allows an attacker access to credential protected resources without first acquiring valid credentials. Examples of this vulnerability include:* SQL injection during login to bypasses credential authentication* Direct access to resources normally beyond an authentication mechanism, such as a login screen, which do not independently validate the users authenticated session.* Failure to enumerate and enforce the systems' access policy. * A weak authentication system that allows a valid identity to be forged. | \n| Significant Authorization Bypass | CWE-285:  Authorization is the concept of allowing access to resources only to those permitted to use them. Vulnerabilities that bypass authorization checks may allow access to protected resources beyond what was intended by the system. Examples of authorization bypass include Insecure Direct Object Reference and Session Token Alteration. In each of these examples, the system trusts the users' requests because of improper or insecure implementation. |\n| Cross Instance Privilege Escalation | Salesforce is a multi-tenant platform in which \"instances\" are created for each Org. A cross-instance privilege escalation involves some user in instance A having access to data in instance B without proper authorization. |\n| Denial of Service | Susceptibility to an external, simply executed, single actor, logic-based attack resulting in a service outage or significant performance degradation of one or more critical systems/products  |\n| Disclosure of Personal Identifiable Information | CWE-200:  Personally identifiable information, or PII, is any data that could potentially be used to identify a particular person. As it relates to Salesforce, PII Disclosure bugs involve PII data stored within any in-scope platforms, excluding Salesforce Employee data such as Name and Contact information.  [src: https://www.lifelock.com/learn-identity-theft-resources-what-is-personally-identifiable-information.html] |\n| Salesforce Platform Misconfiguration and/or Custom APEX Vulnerabilities (Salesforce Owned/Controlled) | The Salesforce Platform is highly configurable, customizable, and supports custom code in the form of APEX code, Visualforce pages, etc. It is therefore capable of being misconfigured in such a way as to leak information or to otherwise be insecure. This category of vulnerability is specific to Salesforce owned and operated sites, NOT Salesforce customer-owned and operated Salesforce instances. If you identify a configuration vulnerability in a customer site please report it to that company via their Bug Bounty program or their security@\u003csome company dot com\u003e email address. There is no guarantee that the customer will respond to your email or bug submission, and it is out of Salesforce control. Please do not expect Salesforce to handle reports of customer misconfiguration.|\n| Privilege Escalation / Improper Access Control | Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in a software application to gain elevated access to resources that are normally protected from an application or user. The result is that a user with more privileges than intended by the application developer or system administrator can perform unauthorized actions. Note that Privilege Escalation is different from Permission Model Circumvention in that PE involves accessing functionality beyond that assigned to a given role, or somehow adding resource permissions to a given role without authorization, while PMC involves a complete bypass of security controls meant to enforce permissions. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access.  [src: https://en.wikipedia.org/wiki/Privilege_escalation] |\n| Non-XXE SSRF | In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.[src:https://www.owasp.org/index.php/Server_Side_Request_Forgery] |\n| Insecure Direct Object Reference | IDOR occurs when unvalidated user-supplied input is submitted and direct access to the object requested is provided. Vulnerability reports for IDOR are valid when the result is unauthorized information disclosure, modification or destruction of data, or performing a function outside of the limits of the current user. |\n| CRLF injection/HTTP response splitting  | HTTP response splitting occurs when data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. [src: https://www.owasp.org/index.php/HTTP_Response_Splitting] |\n| Circumvention of our Platform’s Permission Model | Permission Model Circumvention involves a complete bypass of security controls meant to enforce permissions. An example of PMC involves an insecurely configured system in which an API gateway fronts for several servers and implements authentication/authorization. The configuration is such that the URI to the backend servers can be identified and they are directly accessible without any additional authentication or authorization checks..While there is an authX model in place, it was trivially circumventable. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access. |\n| Cross-Site Scripting (excluding self-XSS) | CWE-80:  Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. [src:https://en.wikipedia.org/wiki/Cross-site_scripting] |\n| Cross-Site Request Forgery (CSRF) on critical actions | CWE-352:  Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.  [src: https://en.wikipedia.org/wiki/Cross-site_request_forgery] |\n| Insufficiently Protected Credentials / Credential Exposure | CWE-522:  CWE-522: Within the context of the Salesforce/HackerOne Bug Bounty program, credential exposure involves finding, or gaining access to a user or system credentials which are not meant to be public. An example of IPC would be finding a Github or other repo containing configuration files that contain usernames, passwords, API keys, private keys, etc. Another example is an exposure of a single user's credentials on the querystring, in cookies, or in other HTTP headers. |\n| Insecure/Open Redirect | CWE-601:  An HTTP parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. |\n| DNS Hijacking / Subdomain Takeover | DNS hijacking or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries.The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.  [src: https://en.wikipedia.org/wiki/DNS_hijacking] [src: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers] |\n| Configuration/Stats//Log File Exposure | CWE-532 Information Exposure Through Log Files. CWE-200: Information Exposure. Any instance in which log files or server/application configuration files are accessible when they are not meant to be. |\n| Documentation Bug | Any instance in which, from a strictly security-based perspective, the published documentation is incorrect with regard to the behavior of the product. | \n\n\n##Non-Qualifying Vulnerabilities (Out of Scope)\n\n\nThe following types of issues are *specifically excluded* from our Bug Bounty Program:\n\n- Attacks requiring physical access to a user's unlocked device\n- Reports of spam, phishing or security best practices\n- Bugs categorized as P3 (low risk)\n- Clickjacking and issues only exploitable through clickjacking\n* CSRF-able actions that do not require authentication (or a session) to exploit or CSRF issues which have no security impact to Slack.\n* HTML and Link injections\n* Issues related to \"Editable Github Wiki Pages\"\n* Issues related to Salesforce *Partner* User Credential Disclosure in public code repositories such as GitHub. *Please note that this type of activity is explicitly excluded by the Conduct Guidelines in this policy.*\n* TOCTOU bugs involving platform permission changes. For example; User A has an active session, Admin reduces or increases permissions for User A, User A permissions do not change until User A logs out and back in. This is currently WAD on Salesforce platforms.\n* Invalid links from any Salesforce site to any social media site in which a claim of \"account takeover\" or \"possible phishing attacks\" are the basis for the report.\n* Bugs in content/services that are not owned/operated by Salesforce\n* Vulnerabilities affecting users of outdated or unsupported browsers or platforms\n* Vulnerabilities that have already been addressed in a product update regardless of whether the update has been applied to the publicly available research machines\n* Subdomain takeovers for out of scope domains\n* Self-XSS or XSS bugs requiring an unlikely amount of user interaction\n* XSS in our content sandbox under .content.force.com (http://content.force.com/)\n- XSS under \\.sitepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.livepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.visual.force.com (with the exception of Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n* XSS in custom apps under .force.com (with the exception of lightning.force.com and Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n- Descriptive error messages (e.g. Stack Traces, application or server errors)\n- HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n- Fingerprinting / banner disclosure on common/public services.\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Scripting or other automation and brute-forcing of intended functionality\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n- Lack of Secure and HTTPOnly cookie flags\n- Content spoofing (text injection) or IDN homograph attacks\n- Tabnabbing \n- Email configuration issues (SPF, DKIM, DMARC)\n- Weak Captcha / Captcha Bypass\n- Forced Login / Logout CSRF\n- Account lockout, Login or Forgot Password page brute force\n- Password complexity or account recovery policies\n- Username / email enumeration (brute force)\n- HTTPS Mixed Content\n- Missing HTTP security headers, specifically: Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy.\n- OPTIONS HTTP method enabled\n- Known SSL issues (e.g. attacks such as BEAST, BREACH, POODLE, TLS Renegotiation)\n- SSL Forward Secrecy or HSTS not enabled\n- Weak SSL/TLS Cipher Suites\n- CSV Excel Formula injection\n- Issues related to networking protocols or industry standards not controlled by Salesforce\n- Sending vulnerability reports using automated tools without validation\n- Use of a known-vulnerable library without evidence of exploitability\n- Reflected XSS involving Adobe Flash files (.swf)\n\n*If you are unsure whether a bug or issue that you discover in a participating service is a non-qualifying vulnerability, please email us at \u003cbugbountymanager@salesforce.com\u003e*\n\n\n_Intellectual Property_\n\n\nParticipating in the Bug Bounty Program does not grant to you or any other third party any rights to any Slack or Salesforce intellectual property, product or service. All rights not otherwise granted herein are expressly reserved. Whether or not we grant you a reward, you hereby assign to Salesforce all right, title and interest (including all intellectual property rights), in the contents of all vulnerability reports that you submit to Salesforce. \n\nBy participating in the Bug Bounty Program, you represent that you have the right to assign all such right, title and interest to us and that your participation in the Bug Bounty Program and assignment of such right, title and interest will not breach any agreement you may have with a third party (e.g. your employer).\n\n\n_Other Terms and Conditions_\n\n\nSalesforce pledges not to pursue a civil action or initiate a complaint to law enforcement against researchers for security research and vulnerability disclosure activities conducted in accordance with this Policy. We consider security research and vulnerability disclosure activities conducted in accordance with this Policy “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA and applicable anti-hacking laws such as Cal. Penal Code 502(c). We waive any DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy.\n\nBy participating in the Bug Bounty Program, you agree to be bound by these rules. These policies will apply to you in addition to, and will not replace, any other terms and conditions that are imposed by HackerOne.\n\n- Your participation in the Bug Bounty Program does not create any kind of employment relationship or partnership between you and Salesforce. You must not hold yourself out as a Salesforce employee or as someone in any way affiliated with Salesforce.\n- You must comply with all applicable laws in connection with your participation in this program. \n- You are responsible for any applicable taxes associated with any reward you receive. \n- Vulnerability reports received prior to the Bug Bounty Program launch are not eligible for rewards and may not be re-submitted for a reward.\n- You will not use any of our trademarks, service marks and logos.\n- We may modify this Policy at any time by posting an updated version of this document.\n- We may terminate this Bug Bounty Program at any time without notice. \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":"2025-08-15T14:31:47.355Z"},{"id":3761203,"new_policy":"## Slack Technologies, LLC, a Salesforce company\n\nOver _$12M_ in bounties awarded across all our H1 Bug Bounty programs since 2015!\n\n\nAt Slack, a Salesforce company, Trust is our #1 value and we take the protection of our customers' data very seriously. As a result, we encourage responsible reporting and disclosure of any vulnerabilities that may be found on our websites, APIs, or applications. \n\nSlack is committed to working with security researchers to verify and address any potential vulnerabilities that are reported to us. If you want to help us make our products safer with the possibility of a reward in the process, you are in the right place!\n\nPlease review these terms before you test and/or report a vulnerability. Slack pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.\n\n##Eligibility for the Bug Bounty Program\n\nUnder our Bug Bounty Program, qualified individuals are encouraged to submit bug reports that detail existing vulnerabilities in certain in-scope Salesforce products and services. In certain circumstances, Salesforce may grant monetary rewards to those who submit vulnerability reports.\n\nWe are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Slack. However, only those researchers that meet the following criteria may be eligible to receive a reward. Some of the requirements to participate in the Bug Bounty Program include:\n\n\n* You must be the first reporter of a vulnerability associated with a participating service (we will also not reward for a known vulnerability which we are actively fixing)\n* You must have personally discovered the vulnerability and you may not report a vulnerability that was discovered by another person (including, and especially, someone who does not qualify to participate in the Bug Bounty Program)\n* You must not be employed by Slack, Salesforce, its subsidiaries, or any related entities, currently or in the last 12 months.\n* You must comply with this Policy when discovering the vulnerability and submitting the vulnerability report\n* Slack or H1 can’t be legally prohibited from rewarding you for any reason\n* Non-automated testing is allowed on production Slack infrastructure, preferably using dedicated test teams. Any testing for cross-team vulnerabilities should be conducted using dedicated teams created and owned by the researcher.\n\n##Conduct Guidelines\n\n\nWhile we encourage you to discover and report to us any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited and will result in disqualification from the Bug Bounty Program:\n\n\n* Disclosing any vulnerabilities or suspected vulnerabilities you discover to any other person without explicit Salesforce authorization\n* Disclosing the contents of any submission to our program without explicit Slack authorization\n* Accessing private information of any person stored on a Slack product or service – You must use test accounts\n* Accessing sensitive information (e.g., credentials)\n* Performing actions that may negatively affect Salesforce system performance or its users (e.g. Spam, Phishing, Brute force, Distributed Denial of Service (DDoS))\n* Conducting any kind of physical attack on Slack personnel, property or data centers\n* Social engineering any Slack employee or contractor\n* Conduct vulnerability testing of participating services using anything other than test accounts (e.g. Developer or Trial Edition instances)\n* Exfiltrating data. Please test only the minimum necessary to validate a vulnerability (we can verify if data exfiltration would be possible from a vulnerability, and will reward with the impact in mind)\n* Violating any laws or breaching any agreements in order to discover vulnerabilities\n\nIf you are testing a publicly viewable area of Slack (eg. https://success.salesforce.com), please remove any test posts or accounts when you are done and refrain from engaging with actual users.\n\n\n##Our Commitment to Researchers\n\n\nIf you submit a vulnerability report, the Salesforce security team and associated development organizations will use reasonable efforts to:\n\n\n\n* Respond in a timely manner, acknowledging receipt of your vulnerability report.\n* Investigate and consider your vulnerability report for eligibility under our Bug Bounty Program within 30 days of submission or less.\n* Notify you when the remediation or other action regarding the vulnerability has been implemented. \n\nSlack Products/Services In Scope for H1 Security Researchers\n\nThe Bug Bounty Program is limited to Slack products as specified within the *scope* section in HackerOne.\n\n\n\n##Qualifying Vulnerabilities \u0026 Bounties (In Scope)\n\n\nThe decision to grant a reward for a vulnerability report, and the value of a reward (if any), is entirely within Salesforce’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the *impact and severity* of the reported vulnerability. \n\n\n* You will qualify for consideration for a reward only if you are the first person to responsibly disclose an unknown vulnerability to us in accordance with these policies. The determination of whether you are the first person is solely within our responsibility. Vulnerabilities must also be relevant, exploitable, and well-documented in the vulnerability report. We are more likely to grant a reward if the vulnerability is specific, fixable and not currently exploited against us or our customers. \n\nThe following table lists our target reward range for different types of vulnerabilities within the published scope. All other vulnerabilities not on this table will also be considered and awarded a bounty on a case by case basis. Additional bounty may be awarded on top of these base amounts, as determined by the Bug Bounty Management team.\n\n###The bounty values provided are subject to change at any time as determined by Salesforce.\n\n|Vulnerability Type | Critical | High | Medium | Low |\n| --- | --- | --- | --- | --- |\n|Authentication Bypass (Cross Org) |\t$10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Authentication Bypass (Same Org) |\t$9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Authorization Bypass / Privilege Escalation (Cross Org) |\t$10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Authorization Bypass / Privilege Escalation (Same Org) | $9,000 | $6,000 | $1,500 | $500 |\n|Circumvention of our Platform’s Permission Model (Cross Org) | $10,000 |\t$7,000 |\t$2,000 |$500 |\n|Circumvention of our Platform’s Permission Model (Same Org) |\t$9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Configuration/Stats//Log File Exposure |\t$5,000 |\t$2,500 |\t$1,000 |\t$250 |\n|CRLF injection/HTTP response splitting |\t$4,000 |\t$2,500 |\t$1,000 |\t$500 |\n|Cross Site Request Forgery (CSRF) |\tN/A | $2,500 | $1,000 | $250 |\n|Cross-Site Scripting (excluding self-XSS) | $5,000 | $3,500 | $1,000 | $250 |\n|Denial of Service | $7,000 |\t$4,000 |\t$1,000 |\t$500 |\n|Disclosure of Credit Card data |\t$14,000 |\t$11,000 |\t$6,000 |\t$500 |\n|Disclosure of Personal Identifiable Information |\t$500 |\t$500 |\t$500 |\t$500 |\n|DNS Hijacking / Subdomain Takeover | $5,000 |\t$2,500 |\t$500 |\t$250 |\n|Documentation Bug | N/A |\tN/A |\tN/A |\t$250 |\n|Excessive Agency |\t$12,000 |\t$9,000 |\t$5,000 |\t$500 |\n|Improper Access Control (Cross Org) |\t$10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Improper Access Control (Same Org) |\t$9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Insecure Direct Object Reference (IDOR) (Cross Org) | $10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Insecure Direct Object Reference (IDOR) (Same Org) | $9,000 | $6,000 |\t$1,500 |\t$500 |\n|Insecure Redirect |\tN/A |\tN/A | $1,000 |\t$250 |\n|Insufficiently Protected Credentials / Credential Exposure |\t$5,000 |\t$2,500 |\t$1,000 |\t$250 |\n|Model Theft |\t$12,000 |\t$9,000 |\t$5,000 |\t$500 |\n|Non-XXE SSRF |\t$5,000 |\t$3,500 |\t$1,500 |\t$500 |\n|Other Information Disclosure |\t$5,000 |\t$2,500 |\t$1,000 |\t$250 |\n|Other Injection (SOQL, Command Injection, RFI, LFI, etc.) | $9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Prompt Injection |\t$20,000 |\t$15,000 |\t$5,000 |\t$500 |\n|Remote Code Execution |\t$17,000 |\t$13,000 | $8,000 |\t$500 |\n|Salesforce-Owned/Controlled Misconfiguration and/or Custom APEX Vulnerabilities | $5,000 |\t$2,500 |\t$1,000 |\t$500 |\n|SQL Injection | $12,000 |\t$9,000 |\t$5,000 |\t$500 |\n|Unrestricted XXE / File System Access |\t$10,500 |\t$7,000 |\t$4,500 |\t$500 |\n\n##Vulnerability Severity Definitions\n\nThe following vulnerability severity definitions are based on internal Salesforce documentation. These definitions are a work in progress. The goal of adding these definitions to our policy is to: \n\n* Allow more efficient report triage\n* Align directly with internal Salesforce vulnerability ranking definitions\n* Remove ambiguity and subjective assignment of severity\n* Promote fair bounty payments\n* Promote researcher satisfaction\n\nIf you have feedback and/or suggestions to help us make these more clear and useful, please email your ideas to bugbountymanager@salesforce.com\n\n###Critical\n\n* Indicators of a ‘Critical’ severity level include but are not limited to vulnerabilities that:\n    * can affect a customer-facing or Slack production asset, or a non-production environment containing production customer data. Such an impact could be the compromise of the confidentiality, integrity of availability of such an asset or data.\n    * can result in compromise of sensitive systems or customer data without user interaction.\n    * can be exploited externally / via an untrusted network.\n    * can be remotely exploited with minimal knowledge, skill, or complexity.\n    * results in a root-level compromise of servers or infrastructure devices when exploited.\n    * have a CVSS or VPR score of 9.0 or greater.\n* Examples include, but are not limited to:\n    * External Remote Code Execution (RCE): Executing potentially harmful code on a server from outside the network that may result in system compromise and possible data exfiltration, depending on the specific implementation and context.\n    * Critical Data Exposure (Single/Cross-Tenant): Potential unauthorized disclosure of sensitive data that could affect one or multiple customers, with impact varying based on data sensitivity and scope of exposure.\n    * Arbitrary Account Takeover: Potentially gaining significant control of user accounts without proper authorization, where the impact depends on the account type and associated permissions.\n    * Privilege Escalation to Root/Admin: Possible elevation of privileges to higher levels on a system that could lead to varying degrees of control over the affected system or infrastructure.\n    * Exploitation of Publicly Known and Actively Exploited Vulnerabilities: Potentially leveraging known flaws that may be under active attack, where impact varies based on the vulnerability context. The Public Disclosure must be older than 30 days if the risk is Critical.\n    * External Logic Flaws Causing Significant Service Disruption: Possible abuse of application logic accessible externally that might cause service disruptions, with impact varying based on affected business functions and duration.\n\n\n###High\n\n* Indicators of a ‘High’ severity level include but are not limited to vulnerabilities that:\n    * can affect production or customer-facing assets, or non-production environments with sensitive data.\n    * allow unauthorized access or modification of sensitive data or elevated privileges, but require more skill or context than Critical vulnerabilities.\n    * allow local users to gain increased privileges.\n    * result in susceptibility to an external, simply executed, single actor, logic-based attacks resulting in significant performance degradation of one or more critical systems/products.\n    * Can be exploited with moderate technical knowledge or skill, and is likely to result in system compromise or denial of service. Example: A publicly available exploit without evidence of active exploitation, or a proof-of-concept exploit.\n    * Have a CVSS or VPR score between 7.0 and 8.9\n* Examples include, but are not limited to:\n    * Privilege Escalation (Limited Scope): Gaining higher access within the application allowing unauthorized access to sensitive data and functionalities.\n    * External Persistent/Stored Cross-Site Scripting (XSS): Permanently injecting malicious scripts into a website, affecting other users potentially leading to session hijacking or defacement.\n    * External Cross-Site Request Forgery (CSRF) on Sensitive Functions: Forcing a user to perform unwanted actions on a web application leading to unauthorized state changes or data manipulation.\n    * External Exposure of Sensitive Information via Stack Traces: Revealing internal application details in error messages potentially leading to sensitive information leakage.\n    * Internal Use of Weak Cryptography (Practically Exploitable): Using breakable encryption within the internal network potentially leading to confidential data disclosure.\n    * Internal Remote Arbitrary Code Execution (Without Mitigating Circumstances): Executing code on an internal server potentially leading to system compromise or partial service disruption.\n    * Internal Command or SQL Injection (Without Mitigating Circumstances): Injecting malicious commands into an internal system or database allowing unauthorized data access/modification/deletion.\n    * Internal Exposure of Sensitive Information: Unauthorized access to data by internal users potentially leading to data breach or privacy violations.\n    * Internal Use of Default or Weak Credentials: Using easily guessed passwords for internal systems allowing unauthorized system access.\n    * Susceptibility to Publicly Disclosed Vulnerabilities (High Impact): Using software with known, dangerous flaws potentially leading to system compromise or data loss.\n    * External Path Traversal: Accessing restricted files or directories on the server from the outside potentially leading to access to sensitive files or code execution.\n    * Server-Side Request Forgery (SSRF): Forcing the server to make requests to unintended locations potentially leading to access to internal services or data exfiltration.\n    * Unrestricted File Upload (High Risk): Uploading files without proper security checks potentially leading to remote code execution or defacement.\n    * XML External Entity (XXE) Injection: Exploiting vulnerabilities in XML processing potentially leading to confidential data disclosure or remote code execution.\n\n\n###Medium\n\n* Indicators of a ‘Medium’ severity level include but are not limited to vulnerabilities that:\n    * may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances.  Such a difficulty could require significant knowledge or skill to exploit, or there may be controls in place to prevent exploitation.\n    * could have had a critical or high impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.\n    * require significant user interaction or chaining with other bugs to escalate impact.\n    * result in susceptibility to external, simply executed, single actor, logic-based attacks resulting in some measurable performance degradation of one or more critical systems/products.\n    * may involve low-sensitivity data or present a limited attack surface.\n    * have a CVSS or VPR score between 4.0 and 6.9.\n* Examples include, but are not limited to:\n    * External Unintended Internal Information Disclosure: Revealing internal details to external users potentially aiding further attacks.\n    * Internal Network/Application Cross-Site Scripting (XSS): Injecting malicious scripts into an internal web application potentially allowing attackers to hijack user sessions or deface internal applications.\n    * Internal Network/Application Cross-Site Request Forgery (CSRF): Forcing an authenticated internal user to perform unwanted actions potentially leading to unauthorized actions on internal applications.\n    * Internal Use of Weak Cryptography (Practically Exploitable by Sophisticated Actors): Using breakable encryption within the internal network potentially allowing sensitive internal data decryption.\n    * Usage of End-of-Life (EoL) Operating Systems or Software (Internal): Running unsupported software on internal systems increasing susceptibility to known vulnerabilities.\n    * External Facing Content Spoofing: Manipulating content to deceive users potentially leading to phishing or reputational damage.\n    * Cleartext Transmission of Sensitive Internal Data: Sending unencrypted sensitive data within the internal network potentially allowing interception of confidential internal data.\n    * Predictable Session Identifiers (Internal): Using easily guessable session tokens within the internal network potentially allowing attackers to hijack legitimate user sessions.\n    * Denial-of-Service (DoS) via Logic Flaws (Single Actor, Simple Execution, Measurable Performance Degradation): Causing a noticeable slowdown or temporary unavailability of a service with minimal effort.\n    * Path Traversal on Internal Resources: Accessing restricted files or directories within the internal network potentially allowing unauthorized access to sensitive internal configuration files or data.\n    * Missing or Ineffective Rate Limiting on Non-Critical Internal Endpoints: Failing to limit requests to certain internal features potentially leading to resource exhaustion. While researchers should always feel free to report discoveries to our program, we will only accept and pay for valid Medium severity issues related to CVEs 6 months past publish date.\n\n###Low\n\n* Indicators of a ‘Low’ severity level includes but is not limited to vulnerabilities that:\n    * do not expose sensitive data or infrastructure.\n    * represent best practice gaps, low-impact misconfigurations, or non-exploitable flaws.\n    * may be more difficult to exploit but could lead to minimal compromise of the confidentiality, integrity, or availability of resources under unlikely circumstances.\n    * require unlikely circumstances to be able to be exploited, or where a successful exploit would have minimal consequences.\n    * require complex prerequisites or attacker access to internal environments.\n    * results in susceptibility to external, simply executed, single actor, logic-based attacks resulting in minor performance degradation of one or more critical systems/products.\n    * have a CVSS or VPR score less than 4.0.\n* Examples include, but are not limited to:\n    * Cross-Site Scripting (XSS) from an Authenticated Customer Admin: Injecting malicious scripts through an admin account potentially leading to minor data theft or defacement within admin scope.\n    * Exposure of Internal Default Pages (e.g., Apache server-status): Revealing server information through standard configuration pages potentially aiding reconnaissance.\n    * Exposure of Server Configuration Information: Leaking details about the server setup slightly increasing attack surface knowledge.\n    * Use of Weak Cryptography Not Practically Exploitable: Using breakable encryption with mitigating factors presenting negligible real-world risk.\n    * External Cross-Site Request Forgery (CSRF) on Non-Sensitive Functions: Forcing a user to perform unimportant actions on a website potentially leading to unwanted minor actions.\n    * Documentation Bugs Revealing Sensitive but Outdated Information: Documentation inaccuracies that, from a security perspective, misrepresent product behavior, including instances where outdated information could reveal sensitive configurations and cause confusion.\n    * HTTP Public Key Pinning (HPKP) Configuration Errors with Fallback: Misconfiguration of certificate pinning with a working backup indicating a configuration issue.\n    * Verbose Error Messages Revealing Non-Sensitive Information: Detailed error outputs exposing internal application structure or non-critical data. The data exposed must be, at some point, important from a security perspective.\n    * Absence of Rate Limiting on Non-Authentication Related, Low-Impact Features: Lack of request limits on unimportant features potentially leading to minor resource exhaustion.\n    * Information Disclosure Through Non-Standard HTTP Headers: Revealing minor information in HTTP headers slightly increasing knowledge for attackers.\n\n\n##Qualifying Vulnerability Descriptions\n\n\n| Category | Description |\n| --- | --- |\n| Remote Code Execution | CWE-94: AKA \"Arbitrary Code Execution\".  Describes a security bug that allows an attacker to execute arbitrary commands or code on a target machine or in a target process. The exploit PoC may include many other vulnerability types, but ultimately the result is p0wnage of the server(s) and/or environment.  [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Disclosure of Credit Card data | CWE-359:  This is self-explanatory. Any security bug which allows disclosure of credit card information to an unauthorized user or system qualifies as Disclosure of Credit Card Data |\n| SQL Injection | CWE-1027:  SQL injection is a code injection technique in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Unrestricted XXE / File System Access | CWE-611:  External XML Entity Injection (XXE) is a specific type of Server Side Request Forgery(SSRF) which affects an XML processing engine server-side on a target. Specifically, blind XXE is when the results are either error-based or cause 3rd party interaction with services such as HTTP, FTP \u0026 DNS. An XXE attack typically occurs when XML input containing a reference to an external entity is processed by a weakly configured parser. An attacker can leverage an XXE attack to access sensitive data and read local or remote files. In a similar manner to SSRF, an attacker could introduce malicious code through Remote Code Execution (RCE).  [scr: https://blog.zsec.uk/out-of-band-xxe-2/]  [src: https://chris-young.net/2018/04/13/xxe-xml-external-entity/] |\n| Significant Authentication Bypass | CWE-305:  Authentication bypass is a vulnerability that allows an attacker access to credential protected resources without first acquiring valid credentials. Examples of this vulnerability include:* SQL injection during login to bypasses credential authentication* Direct access to resources normally beyond an authentication mechanism, such as a login screen, which do not independently validate the users authenticated session.* Failure to enumerate and enforce the systems' access policy. * A weak authentication system that allows a valid identity to be forged. | \n| Significant Authorization Bypass | CWE-285:  Authorization is the concept of allowing access to resources only to those permitted to use them. Vulnerabilities that bypass authorization checks may allow access to protected resources beyond what was intended by the system. Examples of authorization bypass include Insecure Direct Object Reference and Session Token Alteration. In each of these examples, the system trusts the users' requests because of improper or insecure implementation. |\n| Cross Instance Privilege Escalation | Salesforce is a multi-tenant platform in which \"instances\" are created for each Org. A cross-instance privilege escalation involves some user in instance A having access to data in instance B without proper authorization. |\n| Denial of Service | Susceptibility to an external, simply executed, single actor, logic-based attack resulting in a service outage or significant performance degradation of one or more critical systems/products  |\n| Disclosure of Personal Identifiable Information | CWE-200:  Personally identifiable information, or PII, is any data that could potentially be used to identify a particular person. As it relates to Salesforce, PII Disclosure bugs involve PII data stored within any in-scope platforms, excluding Salesforce Employee data such as Name and Contact information.  [src: https://www.lifelock.com/learn-identity-theft-resources-what-is-personally-identifiable-information.html] |\n| Salesforce Platform Misconfiguration and/or Custom APEX Vulnerabilities (Salesforce Owned/Controlled) | The Salesforce Platform is highly configurable, customizable, and supports custom code in the form of APEX code, Visualforce pages, etc. It is therefore capable of being misconfigured in such a way as to leak information or to otherwise be insecure. This category of vulnerability is specific to Salesforce owned and operated sites, NOT Salesforce customer-owned and operated Salesforce instances. If you identify a configuration vulnerability in a customer site please report it to that company via their Bug Bounty program or their security@\u003csome company dot com\u003e email address. There is no guarantee that the customer will respond to your email or bug submission, and it is out of Salesforce control. Please do not expect Salesforce to handle reports of customer misconfiguration.|\n| Privilege Escalation / Improper Access Control | Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in a software application to gain elevated access to resources that are normally protected from an application or user. The result is that a user with more privileges than intended by the application developer or system administrator can perform unauthorized actions. Note that Privilege Escalation is different from Permission Model Circumvention in that PE involves accessing functionality beyond that assigned to a given role, or somehow adding resource permissions to a given role without authorization, while PMC involves a complete bypass of security controls meant to enforce permissions. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access.  [src: https://en.wikipedia.org/wiki/Privilege_escalation] |\n| Non-XXE SSRF | In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.[src:https://www.owasp.org/index.php/Server_Side_Request_Forgery] |\n| Insecure Direct Object Reference | IDOR occurs when unvalidated user-supplied input is submitted and direct access to the object requested is provided. Vulnerability reports for IDOR are valid when the result is unauthorized information disclosure, modification or destruction of data, or performing a function outside of the limits of the current user. |\n| CRLF injection/HTTP response splitting  | HTTP response splitting occurs when data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. [src: https://www.owasp.org/index.php/HTTP_Response_Splitting] |\n| Circumvention of our Platform’s Permission Model | Permission Model Circumvention involves a complete bypass of security controls meant to enforce permissions. An example of PMC involves an insecurely configured system in which an API gateway fronts for several servers and implements authentication/authorization. The configuration is such that the URI to the backend servers can be identified and they are directly accessible without any additional authentication or authorization checks..While there is an authX model in place, it was trivially circumventable. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access. |\n| Cross-Site Scripting (excluding self-XSS) | CWE-80:  Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. [src:https://en.wikipedia.org/wiki/Cross-site_scripting] |\n| Cross-Site Request Forgery (CSRF) on critical actions | CWE-352:  Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.  [src: https://en.wikipedia.org/wiki/Cross-site_request_forgery] |\n| Insufficiently Protected Credentials / Credential Exposure | CWE-522:  CWE-522: Within the context of the Salesforce/HackerOne Bug Bounty program, credential exposure involves finding, or gaining access to a user or system credentials which are not meant to be public. An example of IPC would be finding a Github or other repo containing configuration files that contain usernames, passwords, API keys, private keys, etc. Another example is an exposure of a single user's credentials on the querystring, in cookies, or in other HTTP headers. |\n| Insecure/Open Redirect | CWE-601:  An HTTP parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. |\n| DNS Hijacking / Subdomain Takeover | DNS hijacking or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries.The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.  [src: https://en.wikipedia.org/wiki/DNS_hijacking] [src: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers] |\n| Configuration/Stats//Log File Exposure | CWE-532 Information Exposure Through Log Files. CWE-200: Information Exposure. Any instance in which log files or server/application configuration files are accessible when they are not meant to be. |\n| Documentation Bug | Any instance in which, from a strictly security-based perspective, the published documentation is incorrect with regard to the behavior of the product. | \n\n\n##Non-Qualifying Vulnerabilities (Out of Scope)\n\n\nThe following types of issues are *specifically excluded* from our Bug Bounty Program:\n\n- Attacks requiring physical access to a user's unlocked device\n- Reports of spam, phishing or security best practices\n- Bugs categorized as P3 (low risk)\n- Clickjacking and issues only exploitable through clickjacking\n* CSRF-able actions that do not require authentication (or a session) to exploit or CSRF issues which have no security impact to Slack.\n* HTML and Link injections\n* Issues related to \"Editable Github Wiki Pages\"\n* Issues related to Salesforce *Partner* User Credential Disclosure in public code repositories such as GitHub. *Please note that this type of activity is explicitly excluded by the Conduct Guidelines in this policy.*\n* TOCTOU bugs involving platform permission changes. For example; User A has an active session, Admin reduces or increases permissions for User A, User A permissions do not change until User A logs out and back in. This is currently WAD on Salesforce platforms.\n* Invalid links from any Salesforce site to any social media site in which a claim of \"account takeover\" or \"possible phishing attacks\" are the basis for the report.\n* Bugs in content/services that are not owned/operated by Salesforce\n* Vulnerabilities affecting users of outdated or unsupported browsers or platforms\n* Vulnerabilities that have already been addressed in a product update regardless of whether the update has been applied to the publicly available research machines\n* Subdomain takeovers for out of scope domains\n* Self-XSS or XSS bugs requiring an unlikely amount of user interaction\n* XSS in our content sandbox under .content.force.com (http://content.force.com/)\n- XSS under \\.sitepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.livepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.visual.force.com (with the exception of Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n* XSS in custom apps under .force.com (with the exception of lightning.force.com and Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n- Descriptive error messages (e.g. Stack Traces, application or server errors)\n- HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n- Fingerprinting / banner disclosure on common/public services.\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Scripting or other automation and brute-forcing of intended functionality\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n- Lack of Secure and HTTPOnly cookie flags\n- Content spoofing (text injection) or IDN homograph attacks\n- Tabnabbing \n- Email configuration issues (SPF, DKIM, DMARC)\n- Weak Captcha / Captcha Bypass\n- Forced Login / Logout CSRF\n- Account lockout, Login or Forgot Password page brute force\n- Password complexity or account recovery policies\n- Username / email enumeration (brute force)\n- HTTPS Mixed Content\n- Missing HTTP security headers, specifically: Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy.\n- OPTIONS HTTP method enabled\n- Known SSL issues (e.g. attacks such as BEAST, BREACH, POODLE, TLS Renegotiation)\n- SSL Forward Secrecy or HSTS not enabled\n- Weak SSL/TLS Cipher Suites\n- CSV Excel Formula injection\n- Issues related to networking protocols or industry standards not controlled by Salesforce\n- Sending vulnerability reports using automated tools without validation\n- Use of a known-vulnerable library without evidence of exploitability\n- Reflected XSS involving Adobe Flash files (.swf)\n\n*If you are unsure whether a bug or issue that you discover in a participating service is a non-qualifying vulnerability, please email us at \u003cbugbountymanager@salesforce.com\u003e*\n\n\n_Intellectual Property_\n\n\nParticipating in the Bug Bounty Program does not grant to you or any other third party any rights to any Slack or Salesforce intellectual property, product or service. All rights not otherwise granted herein are expressly reserved. Whether or not we grant you a reward, you hereby assign to Salesforce all right, title and interest (including all intellectual property rights), in the contents of all vulnerability reports that you submit to Salesforce. \n\nBy participating in the Bug Bounty Program, you represent that you have the right to assign all such right, title and interest to us and that your participation in the Bug Bounty Program and assignment of such right, title and interest will not breach any agreement you may have with a third party (e.g. your employer).\n\n\n_Other Terms and Conditions_\n\n\nSalesforce pledges not to pursue a civil action or initiate a complaint to law enforcement against researchers for security research and vulnerability disclosure activities conducted in accordance with this Policy. We consider security research and vulnerability disclosure activities conducted in accordance with this Policy “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA and applicable anti-hacking laws such as Cal. Penal Code 502(c). We waive any DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy.\n\nBy participating in the Bug Bounty Program, you agree to be bound by these rules. These policies will apply to you in addition to, and will not replace, any other terms and conditions that are imposed by HackerOne.\n\n- Your participation in the Bug Bounty Program does not create any kind of employment relationship or partnership between you and Salesforce. You must not hold yourself out as a Salesforce employee or as someone in any way affiliated with Salesforce.\n- You must comply with all applicable laws in connection with your participation in this program. \n- You are responsible for any applicable taxes associated with any reward you receive. \n- Vulnerability reports received prior to the Bug Bounty Program launch are not eligible for rewards and may not be re-submitted for a reward.\n- You will not use any of our trademarks, service marks and logos.\n- We may modify this Policy at any time by posting an updated version of this document.\n- We may terminate this Bug Bounty Program at any time without notice. \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":"2025-08-15T14:23:15.506Z"},{"id":3755515,"new_policy":"## Slack Technologies, LLC, a Salesforce company\n\nOver _$12M_ in bounties awarded across all our H1 Bug Bounty programs since 2015!\n\n\nAt Slack, a Salesforce company, Trust is our #1 value and we take the protection of our customers' data very seriously. As a result, we encourage responsible reporting and disclosure of any vulnerabilities that may be found on our websites, APIs, or applications. \n\nSlack is committed to working with security researchers to verify and address any potential vulnerabilities that are reported to us. If you want to help us make our products safer with the possibility of a reward in the process, you are in the right place!\n\nPlease review these terms before you test and/or report a vulnerability. Slack pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.\n\n##Eligibility for the Bug Bounty Program\n\nUnder our Bug Bounty Program, qualified individuals are encouraged to submit bug reports that detail existing vulnerabilities in certain in-scope Salesforce products and services. In certain circumstances, Salesforce may grant monetary rewards to those who submit vulnerability reports.\n\nWe are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Slack. However, only those researchers that meet the following criteria may be eligible to receive a reward. Some of the requirements to participate in the Bug Bounty Program include:\n\n\n* You must be the first reporter of a vulnerability associated with a participating service (we will also not reward for a known vulnerability which we are actively fixing)\n* You must have personally discovered the vulnerability and you may not report a vulnerability that was discovered by another person (including, and especially, someone who does not qualify to participate in the Bug Bounty Program)\n* You must not be employed by Slack, Salesforce, its subsidiaries, or any related entities, currently or in the last 12 months.\n* You must comply with this Policy when discovering the vulnerability and submitting the vulnerability report\n* Slack or H1 can’t be legally prohibited from rewarding you for any reason\n* Non-automated testing is allowed on production Slack infrastructure, preferably using dedicated test teams. Any testing for cross-team vulnerabilities should be conducted using dedicated teams created and owned by the researcher.\n\n##Conduct Guidelines\n\n\nWhile we encourage you to discover and report to us any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited and will result in disqualification from the Bug Bounty Program:\n\n\n* Disclosing any vulnerabilities or suspected vulnerabilities you discover to any other person without explicit Salesforce authorization\n* Disclosing the contents of any submission to our program without explicit Slack authorization\n* Accessing private information of any person stored on a Slack product or service – You must use test accounts\n* Accessing sensitive information (e.g., credentials)\n* Performing actions that may negatively affect Salesforce system performance or its users (e.g. Spam, Phishing, Brute force, Distributed Denial of Service (DDoS))\n* Conducting any kind of physical attack on Slack personnel, property or data centers\n* Social engineering any Slack employee or contractor\n* Conduct vulnerability testing of participating services using anything other than test accounts (e.g. Developer or Trial Edition instances)\n* Exfiltrating data. Please test only the minimum necessary to validate a vulnerability (we can verify if data exfiltration would be possible from a vulnerability, and will reward with the impact in mind)\n* Violating any laws or breaching any agreements in order to discover vulnerabilities\n\nIf you are testing a publicly viewable area of Slack (eg. https://success.salesforce.com), please remove any test posts or accounts when you are done and refrain from engaging with actual users.\n\n\n##Our Commitment to Researchers\n\n\nIf you submit a vulnerability report, the Salesforce security team and associated development organizations will use reasonable efforts to:\n\n\n\n* Respond in a timely manner, acknowledging receipt of your vulnerability report.\n* Investigate and consider your vulnerability report for eligibility under our Bug Bounty Program within 30 days of submission or less.\n* Notify you when the remediation or other action regarding the vulnerability has been implemented. \n\nSlack Products/Services In Scope for H1 Security Researchers\n\nThe Bug Bounty Program is limited to Slack products as specified within the *scope* section in HackerOne.\n\n\n\n##Qualifying Vulnerabilities \u0026 Bounties (In Scope)\n\n\nThe decision to grant a reward for a vulnerability report, and the value of a reward (if any), is entirely within Salesforce’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the *impact and severity* of the reported vulnerability. \n\n\n* You will qualify for consideration for a reward only if you are the first person to responsibly disclose an unknown vulnerability to us in accordance with these policies. The determination of whether you are the first person is solely within our responsibility. Vulnerabilities must also be relevant, exploitable, and well-documented in the vulnerability report. We are more likely to grant a reward if the vulnerability is specific, fixable and not currently exploited against us or our customers. \n\nThe following table lists our target reward range for different types of vulnerabilities within the published scope. All other vulnerabilities not on this table will also be considered and awarded a bounty on a case by case basis. Additional bounty may be awarded on top of these base amounts, as determined by the Bug Bounty Management team.\n\n###The bounty values provided are subject to change at any time as determined by Salesforce.\n\n|Vulnerability Type | Critical | High | Medium | Low |\n| --- | --- | --- | --- | --- |\n|Authentication Bypass (Cross Org) |\t$10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Authentication Bypass (Same Org) |\t$9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Authorization Bypass / Privilege Escalation (Cross Org) |\t$10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Authorization Bypass / Privilege Escalation (Same Org) | $9,000 | $6,000 | $1,500 | $500 |\n|Circumvention of our Platform’s Permission Model (Cross Org) | $10,000 |\t$7,000 |\t$2,000 |$500 |\n|Circumvention of our Platform’s Permission Model (Same Org) |\t$9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Configuration/Stats//Log File Exposure |\t$5,000 |\t$2,500 |\t$1,000 |\t$250 |\n|CRLF injection/HTTP response splitting |\t$4,000 |\t$2,500 |\t$1,000 |\t$500 |\n|Cross Site Request Forgery (CSRF) |\tN/A | $2,500 | $1,000 | $250 |\n|Cross-Site Scripting (excluding self-XSS) | $5,000 | $3,500 | $1,000 | $250 |\n|Denial of Service | $7,000 |\t$4,000 |\t$1,000 |\t$500 |\n|Disclosure of Credit Card data |\t$14,000 |\t$11,000 |\t$6,000 |\t$500 |\n|Disclosure of Personal Identifiable Information |\t$500 |\t$500 |\t$500 |\t$500 |\n|DNS Hijacking / Subdomain Takeover | $5,000 |\t$2,500 |\t$500 |\t$250 |\n|Documentation Bug | N/A |\tN/A |\tN/A |\t$250 |\n|Excessive Agency |\t$12,000 |\t$9,000 |\t$5,000 |\t$500 |\n|Improper Access Control (Cross Org) |\t$10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Improper Access Control (Same Org) |\t$9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Insecure Direct Object Reference (IDOR) (Cross Org) | $10,000 |\t$7,000 |\t$2,000 |\t$500 |\n|Insecure Direct Object Reference (IDOR) (Same Org) | $9,000 | $6,000 |\t$1,500 |\t$500 |\n|Insecure Redirect |\tN/A |\tN/A | $1,000 |\t$250 |\n|Insufficiently Protected Credentials / Credential Exposure |\t$5,000 |\t$2,500 |\t$1,000 |\t$250 |\n|Model Theft |\t$12,000 |\t$9,000 |\t$5,000 |\t$500 |\n|Non-XXE SSRF |\t$5,000 |\t$3,500 |\t$1,500 |\t$500 |\n|Other Information Disclosure |\t$5,000 |\t$2,500 |\t$1,000 |\t$250 |\n|Other Injection (SOQL, Command Injection, RFI, LFI, etc.) | $9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Prompt Injection |\t$20,000 |\t$15,000 |\t$5,000 |\t$500 |\n|Remote Code Execution |\t$17,000 |\t$13,000 | $8,000 |\t$500 |\n|Salesforce-Owned/Controlled Misconfiguration and/or Custom APEX Vulnerabilities | $5,000 |\t$2,500 |\t$1,000 |\t$500 |\n|SQL Injection | $12,000 |\t$9,000 |\t$5,000 |\t$500 |\n|Unrestricted XXE / File System Access |\t$10,500 |\t$7,000 |\t$4,500 |\t$500 |\n\n##Vulnerability Severity Definitions\n\nThe following vulnerability severity definitions are based on internal Salesforce documentation. These definitions are a work in progress. The goal of adding these definitions to our policy is to: \n\n* Allow more efficient report triage\n* Align directly with internal Salesforce vulnerability ranking definitions\n* Remove ambiguity and subjective assignment of severity\n* Promote fair bounty payments\n* Promote researcher satisfaction\n\nIf you have feedback and/or suggestions to help us make these more clear and useful, please email your ideas to bugbountymanager@salesforce.com\n\n###Critical\n\n* Indicators of a ‘Critical’ severity level include but are not limited to vulnerabilities that:\n    * can affect a customer-facing or Salesforce production asset, or a non-production environment containing production customer data. Such an impact could be the compromise of the confidentiality, integrity of availability of such an asset or data.\n    * can result in compromise of sensitive systems or customer data without user interaction.\n    * can be exploited externally / via an untrusted network.\n    * can be remotely exploited with minimal knowledge, skill, or complexity.\n    * results in a root-level compromise of servers or infrastructure devices when exploited.\n    * have a CVSS or VPR score of 9.0 or greater.\n* Examples include, but are not limited to:\n    * External Remote Code Execution (RCE): Executing potentially harmful code on a server from outside the network that may result in system compromise and possible data exfiltration, depending on the specific implementation and context.\n    * Critical Data Exposure (Single/Cross-Tenant): Potential unauthorized disclosure of sensitive data that could affect one or multiple customers, with impact varying based on data sensitivity and scope of exposure.\n    * Arbitrary Account Takeover: Potentially gaining significant control of user accounts without proper authorization, where the impact depends on the account type and associated permissions.\n    * Privilege Escalation to Root/Admin: Possible elevation of privileges to higher levels on a system that could lead to varying degrees of control over the affected system or infrastructure.\n    * Exploitation of Publicly Known and Actively Exploited Vulnerabilities: Potentially leveraging known flaws that may be under active attack, where impact varies based on the vulnerability context. The Public Disclosure must be older than 30 days if the risk is Critical.\n    * External Logic Flaws Causing Significant Service Disruption: Possible abuse of application logic accessible externally that might cause service disruptions, with impact varying based on affected business functions and duration.\n\n\n###High\n\n* Indicators of a ‘High’ severity level include but are not limited to vulnerabilities that:\n    * can affect production or customer-facing assets, or non-production environments with sensitive data.\n    * allow unauthorized access or modification of sensitive data or elevated privileges, but require more skill or context than Critical vulnerabilities.\n    * allow local users to gain increased privileges.\n    * result in susceptibility to an external, simply executed, single actor, logic-based attacks resulting in significant performance degradation of one or more critical systems/products.\n    * Can be exploited with moderate technical knowledge or skill, and is likely to result in system compromise or denial of service. Example: A publicly available exploit without evidence of active exploitation, or a proof-of-concept exploit.\n    * Have a CVSS or VPR score between 7.0 and 8.9\n* Examples include, but are not limited to:\n    * Privilege Escalation (Limited Scope): Gaining higher access within the application allowing unauthorized access to sensitive data and functionalities.\n    * External Persistent/Stored Cross-Site Scripting (XSS): Permanently injecting malicious scripts into a website, affecting other users potentially leading to session hijacking or defacement.\n    * External Cross-Site Request Forgery (CSRF) on Sensitive Functions: Forcing a user to perform unwanted actions on a web application leading to unauthorized state changes or data manipulation.\n    * External Exposure of Sensitive Information via Stack Traces: Revealing internal application details in error messages potentially leading to sensitive information leakage.\n    * Internal Use of Weak Cryptography (Practically Exploitable): Using breakable encryption within the internal network potentially leading to confidential data disclosure.\n    * Internal Remote Arbitrary Code Execution (Without Mitigating Circumstances): Executing code on an internal server potentially leading to system compromise or partial service disruption.\n    * Internal Command or SQL Injection (Without Mitigating Circumstances): Injecting malicious commands into an internal system or database allowing unauthorized data access/modification/deletion.\n    * Internal Exposure of Sensitive Information: Unauthorized access to data by internal users potentially leading to data breach or privacy violations.\n    * Internal Use of Default or Weak Credentials: Using easily guessed passwords for internal systems allowing unauthorized system access.\n    * Susceptibility to Publicly Disclosed Vulnerabilities (High Impact): Using software with known, dangerous flaws potentially leading to system compromise or data loss.\n    * External Path Traversal: Accessing restricted files or directories on the server from the outside potentially leading to access to sensitive files or code execution.\n    * Server-Side Request Forgery (SSRF): Forcing the server to make requests to unintended locations potentially leading to access to internal services or data exfiltration.\n    * Unrestricted File Upload (High Risk): Uploading files without proper security checks potentially leading to remote code execution or defacement.\n    * XML External Entity (XXE) Injection: Exploiting vulnerabilities in XML processing potentially leading to confidential data disclosure or remote code execution.\n\n\n###Medium\n\n* Indicators of a ‘Medium’ severity level include but are not limited to vulnerabilities that:\n    * may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances.  Such a difficulty could require significant knowledge or skill to exploit, or there may be controls in place to prevent exploitation.\n    * could have had a critical or high impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.\n    * require significant user interaction or chaining with other bugs to escalate impact.\n    * result in susceptibility to external, simply executed, single actor, logic-based attacks resulting in some measurable performance degradation of one or more critical systems/products.\n    * may involve low-sensitivity data or present a limited attack surface.\n    * have a CVSS or VPR score between 4.0 and 6.9.\n* Examples include, but are not limited to:\n    * External Unintended Internal Information Disclosure: Revealing internal details to external users potentially aiding further attacks.\n    * Internal Network/Application Cross-Site Scripting (XSS): Injecting malicious scripts into an internal web application potentially allowing attackers to hijack user sessions or deface internal applications.\n    * Internal Network/Application Cross-Site Request Forgery (CSRF): Forcing an authenticated internal user to perform unwanted actions potentially leading to unauthorized actions on internal applications.\n    * Internal Use of Weak Cryptography (Practically Exploitable by Sophisticated Actors): Using breakable encryption within the internal network potentially allowing sensitive internal data decryption.\n    * Usage of End-of-Life (EoL) Operating Systems or Software (Internal): Running unsupported software on internal systems increasing susceptibility to known vulnerabilities.\n    * External Facing Content Spoofing: Manipulating content to deceive users potentially leading to phishing or reputational damage.\n    * Cleartext Transmission of Sensitive Internal Data: Sending unencrypted sensitive data within the internal network potentially allowing interception of confidential internal data.\n    * Predictable Session Identifiers (Internal): Using easily guessable session tokens within the internal network potentially allowing attackers to hijack legitimate user sessions.\n    * Denial-of-Service (DoS) via Logic Flaws (Single Actor, Simple Execution, Measurable Performance Degradation): Causing a noticeable slowdown or temporary unavailability of a service with minimal effort.\n    * Path Traversal on Internal Resources: Accessing restricted files or directories within the internal network potentially allowing unauthorized access to sensitive internal configuration files or data.\n    * Missing or Ineffective Rate Limiting on Non-Critical Internal Endpoints: Failing to limit requests to certain internal features potentially leading to resource exhaustion. While researchers should always feel free to report discoveries to our program, we will only accept and pay for valid P2 issues related to CVEs 6 months past publish date.\n\n###Low\n\n* Indicators of a ‘Low’ severity level includes but is not limited to vulnerabilities that:\n    * do not expose sensitive data or infrastructure.\n    * represent best practice gaps, low-impact misconfigurations, or non-exploitable flaws.\n    * may be more difficult to exploit but could lead to minimal compromise of the confidentiality, integrity, or availability of resources under unlikely circumstances.\n    * require unlikely circumstances to be able to be exploited, or where a successful exploit would have minimal consequences.\n    * require complex prerequisites or attacker access to internal environments.\n    * results in susceptibility to external, simply executed, single actor, logic-based attacks resulting in minor performance degradation of one or more critical systems/products.\n    * have a CVSS or VPR score less than 4.0.\n* Examples include, but are not limited to:\n    * Cross-Site Scripting (XSS) from an Authenticated Customer Admin: Injecting malicious scripts through an admin account potentially leading to minor data theft or defacement within admin scope.\n    * Exposure of Internal Default Pages (e.g., Apache server-status): Revealing server information through standard configuration pages potentially aiding reconnaissance.\n    * Exposure of Server Configuration Information: Leaking details about the server setup slightly increasing attack surface knowledge.\n    * Use of Weak Cryptography Not Practically Exploitable: Using breakable encryption with mitigating factors presenting negligible real-world risk.\n    * External Cross-Site Request Forgery (CSRF) on Non-Sensitive Functions: Forcing a user to perform unimportant actions on a website potentially leading to unwanted minor actions.\n    * Documentation Bugs Revealing Sensitive but Outdated Information: Documentation inaccuracies that, from a security perspective, misrepresent product behavior, including instances where outdated information could reveal sensitive configurations and cause confusion.\n    * HTTP Public Key Pinning (HPKP) Configuration Errors with Fallback: Misconfiguration of certificate pinning with a working backup indicating a configuration issue.\n    * Verbose Error Messages Revealing Non-Sensitive Information: Detailed error outputs exposing internal application structure or non-critical data. The data exposed must be, at some point, important from a security perspective.\n    * Absence of Rate Limiting on Non-Authentication Related, Low-Impact Features: Lack of request limits on unimportant features potentially leading to minor resource exhaustion.\n    * Information Disclosure Through Non-Standard HTTP Headers: Revealing minor information in HTTP headers slightly increasing knowledge for attackers.\n\n\n##Qualifying Vulnerability Descriptions\n\n\n| Category | Description |\n| --- | --- |\n| Remote Code Execution | CWE-94: AKA \"Arbitrary Code Execution\".  Describes a security bug that allows an attacker to execute arbitrary commands or code on a target machine or in a target process. The exploit PoC may include many other vulnerability types, but ultimately the result is p0wnage of the server(s) and/or environment.  [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Disclosure of Credit Card data | CWE-359:  This is self-explanatory. Any security bug which allows disclosure of credit card information to an unauthorized user or system qualifies as Disclosure of Credit Card Data |\n| SQL Injection | CWE-1027:  SQL injection is a code injection technique in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Unrestricted XXE / File System Access | CWE-611:  External XML Entity Injection (XXE) is a specific type of Server Side Request Forgery(SSRF) which affects an XML processing engine server-side on a target. Specifically, blind XXE is when the results are either error-based or cause 3rd party interaction with services such as HTTP, FTP \u0026 DNS. An XXE attack typically occurs when XML input containing a reference to an external entity is processed by a weakly configured parser. An attacker can leverage an XXE attack to access sensitive data and read local or remote files. In a similar manner to SSRF, an attacker could introduce malicious code through Remote Code Execution (RCE).  [scr: https://blog.zsec.uk/out-of-band-xxe-2/]  [src: https://chris-young.net/2018/04/13/xxe-xml-external-entity/] |\n| Significant Authentication Bypass | CWE-305:  Authentication bypass is a vulnerability that allows an attacker access to credential protected resources without first acquiring valid credentials. Examples of this vulnerability include:* SQL injection during login to bypasses credential authentication* Direct access to resources normally beyond an authentication mechanism, such as a login screen, which do not independently validate the users authenticated session.* Failure to enumerate and enforce the systems' access policy. * A weak authentication system that allows a valid identity to be forged. | \n| Significant Authorization Bypass | CWE-285:  Authorization is the concept of allowing access to resources only to those permitted to use them. Vulnerabilities that bypass authorization checks may allow access to protected resources beyond what was intended by the system. Examples of authorization bypass include Insecure Direct Object Reference and Session Token Alteration. In each of these examples, the system trusts the users' requests because of improper or insecure implementation. |\n| Cross Instance Privilege Escalation | Salesforce is a multi-tenant platform in which \"instances\" are created for each Org. A cross-instance privilege escalation involves some user in instance A having access to data in instance B without proper authorization. |\n| Denial of Service | Susceptibility to an external, simply executed, single actor, logic-based attack resulting in a service outage or significant performance degradation of one or more critical systems/products  |\n| Disclosure of Personal Identifiable Information | CWE-200:  Personally identifiable information, or PII, is any data that could potentially be used to identify a particular person. As it relates to Salesforce, PII Disclosure bugs involve PII data stored within any in-scope platforms, excluding Salesforce Employee data such as Name and Contact information.  [src: https://www.lifelock.com/learn-identity-theft-resources-what-is-personally-identifiable-information.html] |\n| Salesforce Platform Misconfiguration and/or Custom APEX Vulnerabilities (Salesforce Owned/Controlled) | The Salesforce Platform is highly configurable, customizable, and supports custom code in the form of APEX code, Visualforce pages, etc. It is therefore capable of being misconfigured in such a way as to leak information or to otherwise be insecure. This category of vulnerability is specific to Salesforce owned and operated sites, NOT Salesforce customer-owned and operated Salesforce instances. If you identify a configuration vulnerability in a customer site please report it to that company via their Bug Bounty program or their security@\u003csome company dot com\u003e email address. There is no guarantee that the customer will respond to your email or bug submission, and it is out of Salesforce control. Please do not expect Salesforce to handle reports of customer misconfiguration.|\n| Privilege Escalation / Improper Access Control | Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in a software application to gain elevated access to resources that are normally protected from an application or user. The result is that a user with more privileges than intended by the application developer or system administrator can perform unauthorized actions. Note that Privilege Escalation is different from Permission Model Circumvention in that PE involves accessing functionality beyond that assigned to a given role, or somehow adding resource permissions to a given role without authorization, while PMC involves a complete bypass of security controls meant to enforce permissions. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access.  [src: https://en.wikipedia.org/wiki/Privilege_escalation] |\n| Non-XXE SSRF | In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.[src:https://www.owasp.org/index.php/Server_Side_Request_Forgery] |\n| Insecure Direct Object Reference | IDOR occurs when unvalidated user-supplied input is submitted and direct access to the object requested is provided. Vulnerability reports for IDOR are valid when the result is unauthorized information disclosure, modification or destruction of data, or performing a function outside of the limits of the current user. |\n| CRLF injection/HTTP response splitting  | HTTP response splitting occurs when data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. [src: https://www.owasp.org/index.php/HTTP_Response_Splitting] |\n| Circumvention of our Platform’s Permission Model | Permission Model Circumvention involves a complete bypass of security controls meant to enforce permissions. An example of PMC involves an insecurely configured system in which an API gateway fronts for several servers and implements authentication/authorization. The configuration is such that the URI to the backend servers can be identified and they are directly accessible without any additional authentication or authorization checks..While there is an authX model in place, it was trivially circumventable. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access. |\n| Cross-Site Scripting (excluding self-XSS) | CWE-80:  Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. [src:https://en.wikipedia.org/wiki/Cross-site_scripting] |\n| Cross-Site Request Forgery (CSRF) on critical actions | CWE-352:  Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.  [src: https://en.wikipedia.org/wiki/Cross-site_request_forgery] |\n| Insufficiently Protected Credentials / Credential Exposure | CWE-522:  CWE-522: Within the context of the Salesforce/HackerOne Bug Bounty program, credential exposure involves finding, or gaining access to a user or system credentials which are not meant to be public. An example of IPC would be finding a Github or other repo containing configuration files that contain usernames, passwords, API keys, private keys, etc. Another example is an exposure of a single user's credentials on the querystring, in cookies, or in other HTTP headers. |\n| Insecure/Open Redirect | CWE-601:  An HTTP parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. |\n| DNS Hijacking / Subdomain Takeover | DNS hijacking or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries.The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.  [src: https://en.wikipedia.org/wiki/DNS_hijacking] [src: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers] |\n| Configuration/Stats//Log File Exposure | CWE-532 Information Exposure Through Log Files. CWE-200: Information Exposure. Any instance in which log files or server/application configuration files are accessible when they are not meant to be. |\n| Documentation Bug | Any instance in which, from a strictly security-based perspective, the published documentation is incorrect with regard to the behavior of the product. | \n\n\n##Non-Qualifying Vulnerabilities (Out of Scope)\n\n\nThe following types of issues are *specifically excluded* from our Bug Bounty Program:\n\n* CSRF-able actions that do not require authentication (or a session) to exploit or CSRF issues which have no security impact to Slack.\n\n*Commerce Cloud Specific*\n\n* XSS that is stored in Business Manager and is reflected in the storefront / executed in a Storefront context.\n* Admin to Admin or Admin to User XSS. In these cases, a higher privileged user is attempting to attack the lower privileged user. As an admin, such script execution is considered a feature due to the nature of the platform.\n* CSRF in Storefront\n* CSRF that can only be used to make modifications on the file system\n* Session Fixation inside of Storefront\n* XSS in the following areas: HTML Editor and file upload\n* Login Page / Forgot Password Page Account Brute force or account lockout not enforced\n* Submissions regarding product deficiencies, as opposed to exploitable vulnerabilities\n\n*Other Clouds and Services (Including Commerce Cloud)*\n\n* Access control to objects and fields in Salesforce are done through permission set or profile in setup tree. If that permission or profile in the setup tree is not respected, only then it is considered as an access control issue. Please check all permissions \u0026 profiles for that particular user before filling access control bugs.\n* HTML and Link injections\n* Issues related to \"Editable Github Wiki Pages\"\n* Issues related to Salesforce *Partner* User Credential Disclosure in public code repositories such as GitHub. *Please note that this type of activity is explicitly excluded by the Conduct Guidelines in this policy.*\n* TOCTOU bugs involving platform permission changes. For example; User A has an active session, Admin reduces or increases permissions for User A, User A permissions do not change until User A logs out and back in. This is currently WAD on Salesforce platforms.\n* Invalid links from any Salesforce site to any social media site in which a claim of \"account takeover\" or \"possible phishing attacks\" are the basis for the report.\n* Bugs in content/services that are not owned/operated by Salesforce\n* Vulnerabilities affecting users of outdated or unsupported browsers or platforms\n* Vulnerabilities that have already been addressed in a product update regardless of whether the update has been applied to the publicly available research machines\n* Subdomain takeovers for out of scope domains\n* Self-XSS or XSS bugs requiring an unlikely amount of user interaction\n* XSS in our content sandbox under .content.force.com (http://content.force.com/)\n\n- XSS under \\.sitepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.livepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.visual.force.com (with the exception of Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n\n* XSS in custom apps under .force.com (with the exception of lightning.force.com and Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n\n- Bugs categorized as P3 (low risk)\n- SalesforceDX: Attacks by a root user against another user on the same machine\n- SalesforceDX: Attacks by a user on the same user\n- CSRF on forms that are available to anonymous users (e.g. web2lead contact form)\n- Clickjacking and issues only exploitable through clickjacking\n- Descriptive error messages (e.g. Stack Traces, application or server errors)\n- HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n- Fingerprinting / banner disclosure on common/public services.\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Scripting or other automation and brute-forcing of intended functionality\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n- Lack of Secure and HTTPOnly cookie flags\n- Content spoofing (text injection) or IDN homograph attacks\n- Tabnabbing \n- Email configuration issues (SPF, DKIM, DMARC)\n- Weak Captcha / Captcha Bypass\n- Forced Login / Logout CSRF\n- Account lockout, Login or Forgot Password page brute force\n- Password complexity or account recovery policies\n- Username / email enumeration (brute force)\n- HTTPS Mixed Content\n- Missing HTTP security headers, specifically: Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy.\n- OPTIONS HTTP method enabled\n- Known SSL issues (e.g. attacks such as BEAST, BREACH, POODLE, TLS Renegotiation)\n- SSL Forward Secrecy or HSTS not enabled\n- Weak SSL/TLS Cipher Suites\n- CSV Excel Formula injection\n- Issues related to networking protocols or industry standards not controlled by Salesforce\n- Sending vulnerability reports using automated tools without validation\n- Use of a known-vulnerable library without evidence of exploitability\n- Attacks requiring physical access to a user's unlocked device\n- Reports of spam, phishing or security best practices\n- Reflected XSS involving Adobe Flash files (.swf)\n\n*If you are unsure whether a bug or issue that you discover in a participating service is a non-qualifying vulnerability, please email us at \u003cbugbountymanager@salesforce.com\u003e*\n\n\n_Intellectual Property_\n\n\nParticipating in the Bug Bounty Program does not grant to you or any other third party any rights to any Slack or Salesforce intellectual property, product or service. All rights not otherwise granted herein are expressly reserved. Whether or not we grant you a reward, you hereby assign to Salesforce all right, title and interest (including all intellectual property rights), in the contents of all vulnerability reports that you submit to Salesforce. \n\nBy participating in the Bug Bounty Program, you represent that you have the right to assign all such right, title and interest to us and that your participation in the Bug Bounty Program and assignment of such right, title and interest will not breach any agreement you may have with a third party (e.g. your employer).\n\n\n_Other Terms and Conditions_\n\n\nSalesforce pledges not to pursue a civil action or initiate a complaint to law enforcement against researchers for security research and vulnerability disclosure activities conducted in accordance with this Policy. We consider security research and vulnerability disclosure activities conducted in accordance with this Policy “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA and applicable anti-hacking laws such as Cal. Penal Code 502(c). We waive any DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy.\n\nBy participating in the Bug Bounty Program, you agree to be bound by these rules. These policies will apply to you in addition to, and will not replace, any other terms and conditions that are imposed by HackerOne.\n\n- Your participation in the Bug Bounty Program does not create any kind of employment relationship or partnership between you and Salesforce. You must not hold yourself out as a Salesforce employee or as someone in any way affiliated with Salesforce.\n- You must comply with all applicable laws in connection with your participation in this program. \n- You are responsible for any applicable taxes associated with any reward you receive. \n- Vulnerability reports received prior to the Bug Bounty Program launch are not eligible for rewards and may not be re-submitted for a reward.\n- You will not use any of our trademarks, service marks and logos.\n- We may modify this Policy at any time by posting an updated version of this document.\n- We may terminate this Bug Bounty Program at any time without notice. \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":"2025-05-13T18:21:01.416Z"},{"id":3755511,"new_policy":"## Slack Technologies, LLC, a Salesforce company\n\nOver _$12M_ in bounties awarded across all our H1 Bug Bounty programs since 2015!\n\n\nAt Slack, a Salesforce company, Trust is our #1 value and we take the protection of our customers' data very seriously. As a result, we encourage responsible reporting and disclosure of any vulnerabilities that may be found on our websites, APIs, or applications. \n\nSlack is committed to working with security researchers to verify and address any potential vulnerabilities that are reported to us. If you want to help us make our products safer with the possibility of a reward in the process, you are in the right place!\n\nPlease review these terms before you test and/or report a vulnerability. Slack pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.\n\n##Eligibility for the Bug Bounty Program\n\nUnder our Bug Bounty Program, qualified individuals are encouraged to submit bug reports that detail existing vulnerabilities in certain in-scope Salesforce products and services. In certain circumstances, Salesforce may grant monetary rewards to those who submit vulnerability reports.\n\nWe are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Slack. However, only those researchers that meet the following criteria may be eligible to receive a reward. Some of the requirements to participate in the Bug Bounty Program include:\n\n\n* You must be the first reporter of a vulnerability associated with a participating service (we will also not reward for a known vulnerability which we are actively fixing)\n* You must have personally discovered the vulnerability and you may not report a vulnerability that was discovered by another person (including, and especially, someone who does not qualify to participate in the Bug Bounty Program)\n* You must not be employed by Slack, Salesforce, its subsidiaries, or any related entities, currently or in the last 12 months.\n* You must comply with this Policy when discovering the vulnerability and submitting the vulnerability report\n* Slack or H1 can’t be legally prohibited from rewarding you for any reason\n* Non-automated testing is allowed on production Slack infrastructure, preferably using dedicated test teams. Any testing for cross-team vulnerabilities should be conducted using dedicated teams created and owned by the researcher.\n\n##Conduct Guidelines\n\n\nWhile we encourage you to discover and report to us any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited and will result in disqualification from the Bug Bounty Program:\n\n\n* Disclosing any vulnerabilities or suspected vulnerabilities you discover to any other person without explicit Salesforce authorization\n* Disclosing the contents of any submission to our program without explicit Slack authorization\n* Accessing private information of any person stored on a Slack product or service – You must use test accounts\n* Accessing sensitive information (e.g., credentials)\n* Performing actions that may negatively affect Salesforce system performance or its users (e.g. Spam, Phishing, Brute force, Distributed Denial of Service (DDoS))\n* Conducting any kind of physical attack on Slack personnel, property or data centers\n* Social engineering any Slack employee or contractor\n* Conduct vulnerability testing of participating services using anything other than test accounts (e.g. Developer or Trial Edition instances)\n* Exfiltrating data. Please test only the minimum necessary to validate a vulnerability (we can verify if data exfiltration would be possible from a vulnerability, and will reward with the impact in mind)\n* Violating any laws or breaching any agreements in order to discover vulnerabilities\n\nIf you are testing a publicly viewable area of Slack (eg. https://success.salesforce.com), please remove any test posts or accounts when you are done and refrain from engaging with actual users.\n\n\n##Our Commitment to Researchers\n\n\nIf you submit a vulnerability report, the Salesforce security team and associated development organizations will use reasonable efforts to:\n\n\n\n* Respond in a timely manner, acknowledging receipt of your vulnerability report.\n* Investigate and consider your vulnerability report for eligibility under our Bug Bounty Program within 30 days of submission or less.\n* Notify you when the remediation or other action regarding the vulnerability has been implemented. \n\nSlack Products/Services In Scope for H1 Security Researchers\n\nThe Bug Bounty Program is limited to Slack products as specified within the *scope* section in HackerOne.\n\n\n\n##Qualifying Vulnerabilities \u0026 Bounties (In Scope)\n\n\nThe decision to grant a reward for a vulnerability report, and the value of a reward (if any), is entirely within Salesforce’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the *impact and severity* of the reported vulnerability. \n\n\n* You will qualify for consideration for a reward only if you are the first person to responsibly disclose an unknown vulnerability to us in accordance with these policies. The determination of whether you are the first person is solely within our responsibility. Vulnerabilities must also be relevant, exploitable, and well-documented in the vulnerability report. We are more likely to grant a reward if the vulnerability is specific, fixable and not currently exploited against us or our customers. \n\nThe following table lists our target reward range for different types of vulnerabilities within the published scope. All other vulnerabilities not on this table will also be considered and awarded a bounty on a case by case basis. Additional bounty may be awarded on top of these base amounts, as determined by the Bug Bounty Management team.\n\n###The bounty values provided are subject to change at any time as determined by Salesforce.\n\n|Vulnerability Type | Critical | High | Medium | Low |\n| --- | --- | --- | --- | --- |\n|Remote Code Execution | $17,000 |$13,000 | $8,000 | $500 |\n|Disclosure of valid Credit Card Data | $14,000 | $11,000 | $6,000 | $500 |\n|SQL Injection | $12,000 |\t$9,000 |\t$5,000 |\t$500 |\n|Other Injection (SOQL, Command Injection, RFI, LFI, etc.) | $9,000 |\t$6,000 |\t$1,500 |\t$500 |\n|Unrestricted XXE / File System Access | $10,500 |\t$7,000 |\t$4,500 |\t$500 |\n|Authentication / Authorization Bypass / Privilege Escalation / Improper Access Control / Circumvention Platform’s Permission Model / Insecure Direct Object Reference (IDOR) (Cross Org)\t| $10,000 | $7,000 | $2,000 | $500 |\n|Authentication / Authorization Bypass / Privilege Escalation / Improper Access Control / Circumvention Platform’s Permission Model / Insecure Direct Object Reference (IDOR) (Cross Org \u0026 Intentionally Connected via Slack Connect - Relevant to Slack)\t| $9,500 |\t$6,500 |\t$1,750 |\t$500 |\n|Authentication / Authorization Bypass / Privilege Escalation / Improper Access Control / Circumvention Platform’s Permission Model (Same Org) | $9,000 | $6,000 | $1,500 | $500 |\n|Denial of Service | $7,000 |\t $4,000 | $1,000 | $500 |\n|Disclosure of Personal Identifiable Information | $500 | $500 | $500 | $500 |\n|Salesforce Platform Misconfiguration and/or Custom APEX Vulnerabilities (Salesforce Owned/Controlled) | $5,000 | $2,500 | $1,000 | $500 |\n|Non-XXE SSRF | $5,000 |\t$3,500 |\t$1,500 |\t$500 |\n|CRLF injection/HTTP response splitting | $4,000 |\t$2,500 |\t$1,000 |\t$500 |\n|Cross Site Scripting (excluding self-XSS) |\t$5,000 |\t$3,500 |\t$1,000 |\t$250 |\n|Insufficiently Protected Credentials/Credential Exposure |\t$5,000 |\t$2,500 |\t$1,000 |\t$250 |\n|DNS Hijacking / Subdomain Takeover | $5,000 |\t $2,500 | $500 | $250 |\n|Configuration/Stats/Log File Exposure | $5,000 |\t$2,500 |\t$1,000 |\t$250 |\n|Other Information Disclosure | $5,000 | $2,500 | $1,000 | $250 |\n|Cross Site Request Forgery (CSRF) |\tN/A | $2,500 | $1,000 | $250 |\n|Insecure Redirect | N/A | N/A | $1,000 | $250 |\n|Documentation Bug | N/A | N/A | N/A | $250 |\n\n\n\n##Vulnerability Severity Definitions\n\nThe following vulnerability severity definitions are based on internal Salesforce documentation. These definitions are a work in progress. The goal of adding these definitions to our policy is to: \n\n* Allow more efficient report triage\n* Align directly with internal Salesforce vulnerability ranking definitions\n* Remove ambiguity and subjective assignment of severity\n* Promote fair bounty payments\n* Promote researcher satisfaction\n\nIf you have feedback and/or suggestions to help us make these more clear and useful, please email your ideas to bugbountymanager@salesforce.com\n\n###Critical\n\n* Indicators of a ‘Critical’ severity level include but are not limited to vulnerabilities that:\n    * can affect a customer-facing or Salesforce production asset, or a non-production environment containing production customer data. Such an impact could be the compromise of the confidentiality, integrity of availability of such an asset or data.\n    * can result in compromise of sensitive systems or customer data without user interaction.\n    * can be exploited externally / via an untrusted network.\n    * can be remotely exploited with minimal knowledge, skill, or complexity.\n    * results in a root-level compromise of servers or infrastructure devices when exploited.\n    * have a CVSS or VPR score of 9.0 or greater.\n* Examples include, but are not limited to:\n    * External Remote Code Execution (RCE): Executing potentially harmful code on a server from outside the network that may result in system compromise and possible data exfiltration, depending on the specific implementation and context.\n    * Critical Data Exposure (Single/Cross-Tenant): Potential unauthorized disclosure of sensitive data that could affect one or multiple customers, with impact varying based on data sensitivity and scope of exposure.\n    * Arbitrary Account Takeover: Potentially gaining significant control of user accounts without proper authorization, where the impact depends on the account type and associated permissions.\n    * Privilege Escalation to Root/Admin: Possible elevation of privileges to higher levels on a system that could lead to varying degrees of control over the affected system or infrastructure.\n    * Exploitation of Publicly Known and Actively Exploited Vulnerabilities: Potentially leveraging known flaws that may be under active attack, where impact varies based on the vulnerability context. The Public Disclosure must be older than 30 days if the risk is Critical.\n    * External Logic Flaws Causing Significant Service Disruption: Possible abuse of application logic accessible externally that might cause service disruptions, with impact varying based on affected business functions and duration.\n\n\n###High\n\n* Indicators of a ‘High’ severity level include but are not limited to vulnerabilities that:\n    * can affect production or customer-facing assets, or non-production environments with sensitive data.\n    * allow unauthorized access or modification of sensitive data or elevated privileges, but require more skill or context than Critical vulnerabilities.\n    * allow local users to gain increased privileges.\n    * result in susceptibility to an external, simply executed, single actor, logic-based attacks resulting in significant performance degradation of one or more critical systems/products.\n    * Can be exploited with moderate technical knowledge or skill, and is likely to result in system compromise or denial of service. Example: A publicly available exploit without evidence of active exploitation, or a proof-of-concept exploit.\n    * Have a CVSS or VPR score between 7.0 and 8.9\n* Examples include, but are not limited to:\n    * Privilege Escalation (Limited Scope): Gaining higher access within the application allowing unauthorized access to sensitive data and functionalities.\n    * External Persistent/Stored Cross-Site Scripting (XSS): Permanently injecting malicious scripts into a website, affecting other users potentially leading to session hijacking or defacement.\n    * External Cross-Site Request Forgery (CSRF) on Sensitive Functions: Forcing a user to perform unwanted actions on a web application leading to unauthorized state changes or data manipulation.\n    * External Exposure of Sensitive Information via Stack Traces: Revealing internal application details in error messages potentially leading to sensitive information leakage.\n    * Internal Use of Weak Cryptography (Practically Exploitable): Using breakable encryption within the internal network potentially leading to confidential data disclosure.\n    * Internal Remote Arbitrary Code Execution (Without Mitigating Circumstances): Executing code on an internal server potentially leading to system compromise or partial service disruption.\n    * Internal Command or SQL Injection (Without Mitigating Circumstances): Injecting malicious commands into an internal system or database allowing unauthorized data access/modification/deletion.\n    * Internal Exposure of Sensitive Information: Unauthorized access to data by internal users potentially leading to data breach or privacy violations.\n    * Internal Use of Default or Weak Credentials: Using easily guessed passwords for internal systems allowing unauthorized system access.\n    * Susceptibility to Publicly Disclosed Vulnerabilities (High Impact): Using software with known, dangerous flaws potentially leading to system compromise or data loss.\n    * External Path Traversal: Accessing restricted files or directories on the server from the outside potentially leading to access to sensitive files or code execution.\n    * Server-Side Request Forgery (SSRF): Forcing the server to make requests to unintended locations potentially leading to access to internal services or data exfiltration.\n    * Unrestricted File Upload (High Risk): Uploading files without proper security checks potentially leading to remote code execution or defacement.\n    * XML External Entity (XXE) Injection: Exploiting vulnerabilities in XML processing potentially leading to confidential data disclosure or remote code execution.\n\n\n###Medium\n\n* Indicators of a ‘Medium’ severity level include but are not limited to vulnerabilities that:\n    * may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances.  Such a difficulty could require significant knowledge or skill to exploit, or there may be controls in place to prevent exploitation.\n    * could have had a critical or high impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.\n    * require significant user interaction or chaining with other bugs to escalate impact.\n    * result in susceptibility to external, simply executed, single actor, logic-based attacks resulting in some measurable performance degradation of one or more critical systems/products.\n    * may involve low-sensitivity data or present a limited attack surface.\n    * have a CVSS or VPR score between 4.0 and 6.9.\n* Examples include, but are not limited to:\n    * External Unintended Internal Information Disclosure: Revealing internal details to external users potentially aiding further attacks.\n    * Internal Network/Application Cross-Site Scripting (XSS): Injecting malicious scripts into an internal web application potentially allowing attackers to hijack user sessions or deface internal applications.\n    * Internal Network/Application Cross-Site Request Forgery (CSRF): Forcing an authenticated internal user to perform unwanted actions potentially leading to unauthorized actions on internal applications.\n    * Internal Use of Weak Cryptography (Practically Exploitable by Sophisticated Actors): Using breakable encryption within the internal network potentially allowing sensitive internal data decryption.\n    * Usage of End-of-Life (EoL) Operating Systems or Software (Internal): Running unsupported software on internal systems increasing susceptibility to known vulnerabilities.\n    * External Facing Content Spoofing: Manipulating content to deceive users potentially leading to phishing or reputational damage.\n    * Cleartext Transmission of Sensitive Internal Data: Sending unencrypted sensitive data within the internal network potentially allowing interception of confidential internal data.\n    * Predictable Session Identifiers (Internal): Using easily guessable session tokens within the internal network potentially allowing attackers to hijack legitimate user sessions.\n    * Denial-of-Service (DoS) via Logic Flaws (Single Actor, Simple Execution, Measurable Performance Degradation): Causing a noticeable slowdown or temporary unavailability of a service with minimal effort.\n    * Path Traversal on Internal Resources: Accessing restricted files or directories within the internal network potentially allowing unauthorized access to sensitive internal configuration files or data.\n    * Missing or Ineffective Rate Limiting on Non-Critical Internal Endpoints: Failing to limit requests to certain internal features potentially leading to resource exhaustion. While researchers should always feel free to report discoveries to our program, we will only accept and pay for valid P2 issues related to CVEs 6 months past publish date.\n\n###Low\n\n* Indicators of a ‘Low’ severity level includes but is not limited to vulnerabilities that:\n    * do not expose sensitive data or infrastructure.\n    * represent best practice gaps, low-impact misconfigurations, or non-exploitable flaws.\n    * may be more difficult to exploit but could lead to minimal compromise of the confidentiality, integrity, or availability of resources under unlikely circumstances.\n    * require unlikely circumstances to be able to be exploited, or where a successful exploit would have minimal consequences.\n    * require complex prerequisites or attacker access to internal environments.\n    * results in susceptibility to external, simply executed, single actor, logic-based attacks resulting in minor performance degradation of one or more critical systems/products.\n    * have a CVSS or VPR score less than 4.0.\n* Examples include, but are not limited to:\n    * Cross-Site Scripting (XSS) from an Authenticated Customer Admin: Injecting malicious scripts through an admin account potentially leading to minor data theft or defacement within admin scope.\n    * Exposure of Internal Default Pages (e.g., Apache server-status): Revealing server information through standard configuration pages potentially aiding reconnaissance.\n    * Exposure of Server Configuration Information: Leaking details about the server setup slightly increasing attack surface knowledge.\n    * Use of Weak Cryptography Not Practically Exploitable: Using breakable encryption with mitigating factors presenting negligible real-world risk.\n    * External Cross-Site Request Forgery (CSRF) on Non-Sensitive Functions: Forcing a user to perform unimportant actions on a website potentially leading to unwanted minor actions.\n    * Documentation Bugs Revealing Sensitive but Outdated Information: Documentation inaccuracies that, from a security perspective, misrepresent product behavior, including instances where outdated information could reveal sensitive configurations and cause confusion.\n    * HTTP Public Key Pinning (HPKP) Configuration Errors with Fallback: Misconfiguration of certificate pinning with a working backup indicating a configuration issue.\n    * Verbose Error Messages Revealing Non-Sensitive Information: Detailed error outputs exposing internal application structure or non-critical data. The data exposed must be, at some point, important from a security perspective.\n    * Absence of Rate Limiting on Non-Authentication Related, Low-Impact Features: Lack of request limits on unimportant features potentially leading to minor resource exhaustion.\n    * Information Disclosure Through Non-Standard HTTP Headers: Revealing minor information in HTTP headers slightly increasing knowledge for attackers.\n\n\n##Qualifying Vulnerability Descriptions\n\n\n| Category | Description |\n| --- | --- |\n| Remote Code Execution | CWE-94: AKA \"Arbitrary Code Execution\".  Describes a security bug that allows an attacker to execute arbitrary commands or code on a target machine or in a target process. The exploit PoC may include many other vulnerability types, but ultimately the result is p0wnage of the server(s) and/or environment.  [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Disclosure of Credit Card data | CWE-359:  This is self-explanatory. Any security bug which allows disclosure of credit card information to an unauthorized user or system qualifies as Disclosure of Credit Card Data |\n| SQL Injection | CWE-1027:  SQL injection is a code injection technique in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Unrestricted XXE / File System Access | CWE-611:  External XML Entity Injection (XXE) is a specific type of Server Side Request Forgery(SSRF) which affects an XML processing engine server-side on a target. Specifically, blind XXE is when the results are either error-based or cause 3rd party interaction with services such as HTTP, FTP \u0026 DNS. An XXE attack typically occurs when XML input containing a reference to an external entity is processed by a weakly configured parser. An attacker can leverage an XXE attack to access sensitive data and read local or remote files. In a similar manner to SSRF, an attacker could introduce malicious code through Remote Code Execution (RCE).  [scr: https://blog.zsec.uk/out-of-band-xxe-2/]  [src: https://chris-young.net/2018/04/13/xxe-xml-external-entity/] |\n| Significant Authentication Bypass | CWE-305:  Authentication bypass is a vulnerability that allows an attacker access to credential protected resources without first acquiring valid credentials. Examples of this vulnerability include:* SQL injection during login to bypasses credential authentication* Direct access to resources normally beyond an authentication mechanism, such as a login screen, which do not independently validate the users authenticated session.* Failure to enumerate and enforce the systems' access policy. * A weak authentication system that allows a valid identity to be forged. | \n| Significant Authorization Bypass | CWE-285:  Authorization is the concept of allowing access to resources only to those permitted to use them. Vulnerabilities that bypass authorization checks may allow access to protected resources beyond what was intended by the system. Examples of authorization bypass include Insecure Direct Object Reference and Session Token Alteration. In each of these examples, the system trusts the users' requests because of improper or insecure implementation. |\n| Cross Instance Privilege Escalation | Salesforce is a multi-tenant platform in which \"instances\" are created for each Org. A cross-instance privilege escalation involves some user in instance A having access to data in instance B without proper authorization. |\n| Denial of Service | Susceptibility to an external, simply executed, single actor, logic-based attack resulting in a service outage or significant performance degradation of one or more critical systems/products  |\n| Disclosure of Personal Identifiable Information | CWE-200:  Personally identifiable information, or PII, is any data that could potentially be used to identify a particular person. As it relates to Salesforce, PII Disclosure bugs involve PII data stored within any in-scope platforms, excluding Salesforce Employee data such as Name and Contact information.  [src: https://www.lifelock.com/learn-identity-theft-resources-what-is-personally-identifiable-information.html] |\n| Salesforce Platform Misconfiguration and/or Custom APEX Vulnerabilities (Salesforce Owned/Controlled) | The Salesforce Platform is highly configurable, customizable, and supports custom code in the form of APEX code, Visualforce pages, etc. It is therefore capable of being misconfigured in such a way as to leak information or to otherwise be insecure. This category of vulnerability is specific to Salesforce owned and operated sites, NOT Salesforce customer-owned and operated Salesforce instances. If you identify a configuration vulnerability in a customer site please report it to that company via their Bug Bounty program or their security@\u003csome company dot com\u003e email address. There is no guarantee that the customer will respond to your email or bug submission, and it is out of Salesforce control. Please do not expect Salesforce to handle reports of customer misconfiguration.|\n| Privilege Escalation / Improper Access Control | Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in a software application to gain elevated access to resources that are normally protected from an application or user. The result is that a user with more privileges than intended by the application developer or system administrator can perform unauthorized actions. Note that Privilege Escalation is different from Permission Model Circumvention in that PE involves accessing functionality beyond that assigned to a given role, or somehow adding resource permissions to a given role without authorization, while PMC involves a complete bypass of security controls meant to enforce permissions. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access.  [src: https://en.wikipedia.org/wiki/Privilege_escalation] |\n| Non-XXE SSRF | In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.[src:https://www.owasp.org/index.php/Server_Side_Request_Forgery] |\n| Insecure Direct Object Reference | IDOR occurs when unvalidated user-supplied input is submitted and direct access to the object requested is provided. Vulnerability reports for IDOR are valid when the result is unauthorized information disclosure, modification or destruction of data, or performing a function outside of the limits of the current user. |\n| CRLF injection/HTTP response splitting  | HTTP response splitting occurs when data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. [src: https://www.owasp.org/index.php/HTTP_Response_Splitting] |\n| Circumvention of our Platform’s Permission Model | Permission Model Circumvention involves a complete bypass of security controls meant to enforce permissions. An example of PMC involves an insecurely configured system in which an API gateway fronts for several servers and implements authentication/authorization. The configuration is such that the URI to the backend servers can be identified and they are directly accessible without any additional authentication or authorization checks..While there is an authX model in place, it was trivially circumventable. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access. |\n| Cross-Site Scripting (excluding self-XSS) | CWE-80:  Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. [src:https://en.wikipedia.org/wiki/Cross-site_scripting] |\n| Cross-Site Request Forgery (CSRF) on critical actions | CWE-352:  Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.  [src: https://en.wikipedia.org/wiki/Cross-site_request_forgery] |\n| Insufficiently Protected Credentials / Credential Exposure | CWE-522:  CWE-522: Within the context of the Salesforce/HackerOne Bug Bounty program, credential exposure involves finding, or gaining access to a user or system credentials which are not meant to be public. An example of IPC would be finding a Github or other repo containing configuration files that contain usernames, passwords, API keys, private keys, etc. Another example is an exposure of a single user's credentials on the querystring, in cookies, or in other HTTP headers. |\n| Insecure/Open Redirect | CWE-601:  An HTTP parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. |\n| DNS Hijacking / Subdomain Takeover | DNS hijacking or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries.The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.  [src: https://en.wikipedia.org/wiki/DNS_hijacking] [src: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers] |\n| Configuration/Stats//Log File Exposure | CWE-532 Information Exposure Through Log Files. CWE-200: Information Exposure. Any instance in which log files or server/application configuration files are accessible when they are not meant to be. |\n| Documentation Bug | Any instance in which, from a strictly security-based perspective, the published documentation is incorrect with regard to the behavior of the product. | \n\n\n##Non-Qualifying Vulnerabilities (Out of Scope)\n\n\nThe following types of issues are *specifically excluded* from our Bug Bounty Program:\n\n* CSRF-able actions that do not require authentication (or a session) to exploit or CSRF issues which have no security impact to Slack.\n\n*Commerce Cloud Specific*\n\n* XSS that is stored in Business Manager and is reflected in the storefront / executed in a Storefront context.\n* Admin to Admin or Admin to User XSS. In these cases, a higher privileged user is attempting to attack the lower privileged user. As an admin, such script execution is considered a feature due to the nature of the platform.\n* CSRF in Storefront\n* CSRF that can only be used to make modifications on the file system\n* Session Fixation inside of Storefront\n* XSS in the following areas: HTML Editor and file upload\n* Login Page / Forgot Password Page Account Brute force or account lockout not enforced\n* Submissions regarding product deficiencies, as opposed to exploitable vulnerabilities\n\n*Other Clouds and Services (Including Commerce Cloud)*\n\n* Access control to objects and fields in Salesforce are done through permission set or profile in setup tree. If that permission or profile in the setup tree is not respected, only then it is considered as an access control issue. Please check all permissions \u0026 profiles for that particular user before filling access control bugs.\n* HTML and Link injections\n* Issues related to \"Editable Github Wiki Pages\"\n* Issues related to Salesforce *Partner* User Credential Disclosure in public code repositories such as GitHub. *Please note that this type of activity is explicitly excluded by the Conduct Guidelines in this policy.*\n* TOCTOU bugs involving platform permission changes. For example; User A has an active session, Admin reduces or increases permissions for User A, User A permissions do not change until User A logs out and back in. This is currently WAD on Salesforce platforms.\n* Invalid links from any Salesforce site to any social media site in which a claim of \"account takeover\" or \"possible phishing attacks\" are the basis for the report.\n* Bugs in content/services that are not owned/operated by Salesforce\n* Vulnerabilities affecting users of outdated or unsupported browsers or platforms\n* Vulnerabilities that have already been addressed in a product update regardless of whether the update has been applied to the publicly available research machines\n* Subdomain takeovers for out of scope domains\n* Self-XSS or XSS bugs requiring an unlikely amount of user interaction\n* XSS in our content sandbox under .content.force.com (http://content.force.com/)\n\n- XSS under \\.sitepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.livepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.visual.force.com (with the exception of Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n\n* XSS in custom apps under .force.com (with the exception of lightning.force.com and Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n\n- Bugs categorized as P3 (low risk)\n- SalesforceDX: Attacks by a root user against another user on the same machine\n- SalesforceDX: Attacks by a user on the same user\n- CSRF on forms that are available to anonymous users (e.g. web2lead contact form)\n- Clickjacking and issues only exploitable through clickjacking\n- Descriptive error messages (e.g. Stack Traces, application or server errors)\n- HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n- Fingerprinting / banner disclosure on common/public services.\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Scripting or other automation and brute-forcing of intended functionality\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n- Lack of Secure and HTTPOnly cookie flags\n- Content spoofing (text injection) or IDN homograph attacks\n- Tabnabbing \n- Email configuration issues (SPF, DKIM, DMARC)\n- Weak Captcha / Captcha Bypass\n- Forced Login / Logout CSRF\n- Account lockout, Login or Forgot Password page brute force\n- Password complexity or account recovery policies\n- Username / email enumeration (brute force)\n- HTTPS Mixed Content\n- Missing HTTP security headers, specifically: Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy.\n- OPTIONS HTTP method enabled\n- Known SSL issues (e.g. attacks such as BEAST, BREACH, POODLE, TLS Renegotiation)\n- SSL Forward Secrecy or HSTS not enabled\n- Weak SSL/TLS Cipher Suites\n- CSV Excel Formula injection\n- Issues related to networking protocols or industry standards not controlled by Salesforce\n- Sending vulnerability reports using automated tools without validation\n- Use of a known-vulnerable library without evidence of exploitability\n- Attacks requiring physical access to a user's unlocked device\n- Reports of spam, phishing or security best practices\n- Reflected XSS involving Adobe Flash files (.swf)\n\n*If you are unsure whether a bug or issue that you discover in a participating service is a non-qualifying vulnerability, please email us at \u003cbugbountymanager@salesforce.com\u003e*\n\n\n_Intellectual Property_\n\n\nParticipating in the Bug Bounty Program does not grant to you or any other third party any rights to any Slack or Salesforce intellectual property, product or service. All rights not otherwise granted herein are expressly reserved. Whether or not we grant you a reward, you hereby assign to Salesforce all right, title and interest (including all intellectual property rights), in the contents of all vulnerability reports that you submit to Salesforce. \n\nBy participating in the Bug Bounty Program, you represent that you have the right to assign all such right, title and interest to us and that your participation in the Bug Bounty Program and assignment of such right, title and interest will not breach any agreement you may have with a third party (e.g. your employer).\n\n\n_Other Terms and Conditions_\n\n\nSalesforce pledges not to pursue a civil action or initiate a complaint to law enforcement against researchers for security research and vulnerability disclosure activities conducted in accordance with this Policy. We consider security research and vulnerability disclosure activities conducted in accordance with this Policy “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA and applicable anti-hacking laws such as Cal. Penal Code 502(c). We waive any DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy.\n\nBy participating in the Bug Bounty Program, you agree to be bound by these rules. These policies will apply to you in addition to, and will not replace, any other terms and conditions that are imposed by HackerOne.\n\n- Your participation in the Bug Bounty Program does not create any kind of employment relationship or partnership between you and Salesforce. You must not hold yourself out as a Salesforce employee or as someone in any way affiliated with Salesforce.\n- You must comply with all applicable laws in connection with your participation in this program. \n- You are responsible for any applicable taxes associated with any reward you receive. \n- Vulnerability reports received prior to the Bug Bounty Program launch are not eligible for rewards and may not be re-submitted for a reward.\n- You will not use any of our trademarks, service marks and logos.\n- We may modify this Policy at any time by posting an updated version of this document.\n- We may terminate this Bug Bounty Program at any time without notice. \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":"2025-05-13T18:03:26.547Z"},{"id":3748946,"new_policy":"## Slack Technologies, LLC, a Salesforce company\n\nOver _$12M_ in bounties awarded across all our H1 Bug Bounty programs since 2015!\n\n\nAt Slack, a Salesforce company, Trust is our #1 value and we take the protection of our customers' data very seriously. As a result, we encourage responsible reporting and disclosure of any vulnerabilities that may be found on our websites, APIs, or applications. \n\nSlack is committed to working with security researchers to verify and address any potential vulnerabilities that are reported to us. If you want to help us make our products safer with the possibility of a reward in the process, you are in the right place!\n\nPlease review these terms before you test and/or report a vulnerability. Slack pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.\n\n*Eligibility for the Bug Bounty Program*\n\nUnder our Bug Bounty Program, qualified individuals are encouraged to submit bug reports that detail existing vulnerabilities in certain in-scope Salesforce products and services. In certain circumstances, Salesforce may grant monetary rewards to those who submit vulnerability reports.\n\nWe are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Slack. However, only those researchers that meet the following criteria may be eligible to receive a reward. Some of the requirements to participate in the Bug Bounty Program include:\n\n\n* You must be the first reporter of a vulnerability associated with a participating service (we will also not reward for a known vulnerability which we are actively fixing)\n* You must have personally discovered the vulnerability and you may not report a vulnerability that was discovered by another person (including, and especially, someone who does not qualify to participate in the Bug Bounty Program)\n* You must not be employed by Slack, Salesforce, its subsidiaries, or any related entities, currently or in the last 12 months.\n* You must comply with this Policy when discovering the vulnerability and submitting the vulnerability report\n* Slack or H1 can’t be legally prohibited from rewarding you for any reason\n* Non-automated testing is allowed on production Slack infrastructure, preferably using dedicated test teams. Any testing for cross-team vulnerabilities should be conducted using dedicated teams created and owned by the researcher.\n\n*Conduct Guidelines*\n\n\nWhile we encourage you to discover and report to us any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited and will result in disqualification from the Bug Bounty Program:\n\n\n* Disclosing any vulnerabilities or suspected vulnerabilities you discover to any other person without explicit Salesforce authorization\n* Disclosing the contents of any submission to our program without explicit Slack authorization\n* Accessing private information of any person stored on a Slack product or service – You must use test accounts\n* Accessing sensitive information (e.g., credentials)\n* Performing actions that may negatively affect Salesforce system performance or its users (e.g. Spam, Phishing, Brute force, Distributed Denial of Service (DDoS))\n* Conducting any kind of physical attack on Slack personnel, property or data centers\n* Social engineering any Slack employee or contractor\n* Conduct vulnerability testing of participating services using anything other than test accounts (e.g. Developer or Trial Edition instances)\n* Exfiltrating data. Please test only the minimum necessary to validate a vulnerability (we can verify if data exfiltration would be possible from a vulnerability, and will reward with the impact in mind)\n* Violating any laws or breaching any agreements in order to discover vulnerabilities\n\nIf you are testing a publicly viewable area of Slack (eg. https://success.salesforce.com), please remove any test posts or accounts when you are done and refrain from engaging with actual users.\n\n\n*Our Commitment to Researchers*\n\n\nIf you submit a vulnerability report, the Salesforce security team and associated development organizations will use reasonable efforts to:\n\n\n\n* Respond in a timely manner, acknowledging receipt of your vulnerability report.\n* Investigate and consider your vulnerability report for eligibility under our Bug Bounty Program within 30 days of submission or less.\n* Notify you when the remediation or other action regarding the vulnerability has been implemented. \n\nSlack Products/Services In Scope for H1 Security Researchers\n\nThe Bug Bounty Program is limited to Slack products as specified within the *scope* section in HackerOne.\n\n\n\n*Qualifying Vulnerabilities \u0026 Bounties (In Scope)*\n\n\nThe decision to grant a reward for a vulnerability report, and the value of a reward (if any), is entirely within Salesforce’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the *impact and severity* of the reported vulnerability. \n\n\n* You will qualify for consideration for a reward only if you are the first person to responsibly disclose an unknown vulnerability to us in accordance with these policies. The determination of whether you are the first person is solely within our responsibility. Vulnerabilities must also be relevant, exploitable, and well-documented in the vulnerability report. We are more likely to grant a reward if the vulnerability is specific, fixable and not currently exploited against us or our customers. \n\nOur target reward range for different types of vulnerabilities within the published scope. Additional bounty may be awarded on top of these base amounts, as determined by the Bug Bounty Management team.\n\n\n*Vulnerability Severity Definitions*\n\nThe following vulnerability severity definitions are based on internal Salesforce documentation. These definitional are a work in progress. The goal of adding these definitions to our policy is to: \n\n* Allow more efficient report triage\n* Align directly with internal Salesforce vulnerability ranking definitions\n* Remove ambiguity and subjective assignment of severity\n* Promote fair bounty payments\n* Promote researcher satisfaction\n\nIf you have feedback and/or suggestions to help us make these more clear and useful, please email your ideas to bugbountymanager@salesforce.com\n\n*Critical*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that can compromise the confidentiality, integrity, or availability of production and corporate resources and/or data with limited exploitation difficulty and/or attacker skill.\n    * Vulnerabilities that could be easily exploited by a remote or unauthenticated attacker and lead to system compromise and/or exposure of highly sensitive or customer data of any kind without requiring user interaction. \n    * Exploitation of a vulnerability that results in a root-level compromise of servers or infrastructure devices.\n* Examples include, but are not limited to:\n    * External facing remote arbitrary code execution without mitigating circumstances. \n    * External facing SQL injection. \n    * External facing unintended single tenant or cross tenant information disclosure and/or multi-tenancy break\n    * Authentication flaws resulting in arbitrary account compromise.\n    * Session management flaws leading to arbitrary account compromise. \n    * External facing credential leaks and default credential usage resulting in access to production systems containing customer data.\n    * Client and server software and system s susceptible to publicly disclosed and exploited vulnerability.\n    * Susceptibility to an external, simply executed, single actor, logic-based attacks resulting in a service outage of one or more critical systems/products.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Critical (In a small subset of cases)\n    * CVSSv3 Temporal Score: 9-10\n    * Qualys Severity 5\n    * nCircle: 1000+ (Based on risk )\n    * PCI Violating Vulnerability: Yes\n    * AppDetective: High (Based on risk )\n    * Whitehat: Urgent\n\n*High*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that can compromise the confidentiality, integrity, or availability of production and corporate resources and data.\n    * Vulnerabilities that could be easily exploited by an internal and/or external, authenticated/unauthenticated attacker and lead to system compromise and/or exposure of highly sensitive or customer data without requiring user interaction.\n    * Vulnerabilities that allow local users to gain increased privileges.\n    * Vulnerabilities that allow unauthenticated remote users to view sensitive information.\n    * Susceptibility to an external, simply executed, single actor, logic-based attacks resulting in significant performance degradation of one or more critical systems/products.\n* Examples include, but are not limited to:\n    * Privilege Escalation  \n    * External facing Persistent/Stored Cross-Site Scripting (XSS).\n    * External facing Cross-Site Request Forgery (CSRF) exposure on sensitive or critical functions.\n    * External facing stack traces containing sensitive information exposed to clients.\n    * Internal network/system use of weak cryptography that is practically exploitable in a real kill chain without nation-state resources.\n    * Internal network/system remote arbitrary code execution without mitigating circumstances.\n    * Internal network/system command or SQL injection without mitigating circumstances.\n    * Internal network/system exposure of sensitive information.\n    * Internal network/system use of default or weak credentials.\n    * Client/Server software and/or systems susceptible to publicly disclosed vulnerability.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Critical/Severe\n    * CVSSv3 Temporal Score: 7 - 8.93\n    * Qualys: Severity 44\n    * nCircle:1000 +\n    * PCI Violating Vuln: Yes\n    * AppDetective: High\n    * Whitehat: Critical\n\n*Medium*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. \n    * Vulnerabilities that could have had a critical or high impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.\n    * Susceptibility to external, simply executed, single actor, logic-based attacks resulting in some measurable performance degradation of one or more critical systems/products.\n* Examples include, but are not limited to:\n    * External unintended internal information disclosure.\n    * Internal network/application Cross-Site Scripting (XSS).\n    * Internal network/application Cross-Site Request Forgery (CSRF).\n    * Internal use of weak cryptography that is practically exploitable in a real kill chain with nation-state resources.\n    * Usage of EoL operating systems or software.\n    * External facing content spoofing.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Moderate\n    * CVSSv3 Temporal Score: 4 - 6.93\n    * Qualys: Severity 34. \n    * nCircle: 500 - 999.5. \n    * PCI Violating Vuln: No\n    * AppDetective: Medium\n    * Whitehat: High\n\n*Low*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that may be more difficult to exploit but could lead to minimal compromise of the confidentiality, integrity, or availability of resources under unlikely circumstances.\n    * These types of vulnerabilities require unlikely circumstances to be able to be exploited, or where a successful exploit would have minimal consequences.\n    * Susceptibility to external, simply executed, single actor, logic-based attacks resulting in minor performance degradation of one or more critical systems/products. \n* Examples include, but are not limited to:\n    * XSS from an authenticated customer admin\n    * Internal default pages or content without vulnerabilities such as an Apache server-status page enabled, allowing anyone browsing it to see the information of the server, as well as any request currently being made.\n    * Exposure of server config information\n    * Use of weak cryptography that is not practically exploitable in a real kill-chain.\n    * Documentation bugs\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Moderate (Informational in nature)\n    * CVSSv3 Temporal Score: 0.1 -3.93\n    * Qualys: Severity 24\n    * nCircle: 1 -499.5.\n    * PCI Violating Vuln: No\n    * AppDetective: Low 7\n    * Whitehat: Low\n\n*Qualifying Vulnerability Descriptions*\n\n\n| Category | Description |\n| --- | --- |\n| Remote Code Execution | CWE-94: AKA \"Arbitrary Code Execution\".  Describes a security bug that allows an attacker to execute arbitrary commands or code on a target machine or in a target process. The exploit PoC may include many other vulnerability types, but ultimately the result is p0wnage of the server(s) and/or environment.  [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Disclosure of Credit Card data | CWE-359:  This is self-explanatory. Any security bug which allows disclosure of credit card information to an unauthorized user or system qualifies as Disclosure of Credit Card Data |\n| SQL Injection | CWE-1027:  SQL injection is a code injection technique in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Unrestricted XXE / File System Access | CWE-611:  External XML Entity Injection (XXE) is a specific type of Server Side Request Forgery(SSRF) which affects an XML processing engine server-side on a target. Specifically, blind XXE is when the results are either error-based or cause 3rd party interaction with services such as HTTP, FTP \u0026 DNS. An XXE attack typically occurs when XML input containing a reference to an external entity is processed by a weakly configured parser. An attacker can leverage an XXE attack to access sensitive data and read local or remote files. In a similar manner to SSRF, an attacker could introduce malicious code through Remote Code Execution (RCE).  [scr: https://blog.zsec.uk/out-of-band-xxe-2/]  [src: https://chris-young.net/2018/04/13/xxe-xml-external-entity/] |\n| Significant Authentication Bypass | CWE-305:  Authentication bypass is a vulnerability that allows an attacker access to credential protected resources without first acquiring valid credentials. Examples of this vulnerability include:* SQL injection during login to bypasses credential authentication* Direct access to resources normally beyond an authentication mechanism, such as a login screen, which do not independently validate the users authenticated session.* Failure to enumerate and enforce the systems' access policy. * A weak authentication system that allows a valid identity to be forged. | \n| Significant Authorization Bypass | CWE-285:  Authorization is the concept of allowing access to resources only to those permitted to use them. Vulnerabilities that bypass authorization checks may allow access to protected resources beyond what was intended by the system. Examples of authorization bypass include Insecure Direct Object Reference and Session Token Alteration. In each of these examples, the system trusts the users' requests because of improper or insecure implementation. |\n| Cross Instance Privilege Escalation | Salesforce is a multi-tenant platform in which \"instances\" are created for each Org. A cross-instance privilege escalation involves some user in instance A having access to data in instance B without proper authorization. |\n| Denial of Service | Susceptibility to an external, simply executed, single actor, logic-based attack resulting in a service outage or significant performance degradation of one or more critical systems/products  |\n| Disclosure of Personal Identifiable Information | CWE-200:  Personally identifiable information, or PII, is any data that could potentially be used to identify a particular person. As it relates to Salesforce, PII Disclosure bugs involve PII data stored within any in-scope platforms, excluding Salesforce Employee data such as Name and Contact information.  [src: https://www.lifelock.com/learn-identity-theft-resources-what-is-personally-identifiable-information.html] |\n| Salesforce Platform Misconfiguration and/or Custom APEX Vulnerabilities (Salesforce Owned/Controlled) | The Salesforce Platform is highly configurable, customizable, and supports custom code in the form of APEX code, Visualforce pages, etc. It is therefore capable of being misconfigured in such a way as to leak information or to otherwise be insecure. This category of vulnerability is specific to Salesforce owned and operated sites, NOT Salesforce customer-owned and operated Salesforce instances. If you identify a configuration vulnerability in a customer site please report it to that company via their Bug Bounty program or their security@\u003csome company dot com\u003e email address. There is no guarantee that the customer will respond to your email or bug submission, and it is out of Salesforce control. Please do not expect Salesforce to handle reports of customer misconfiguration.|\n| Privilege Escalation / Improper Access Control | Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in a software application to gain elevated access to resources that are normally protected from an application or user. The result is that a user with more privileges than intended by the application developer or system administrator can perform unauthorized actions. Note that Privilege Escalation is different from Permission Model Circumvention in that PE involves accessing functionality beyond that assigned to a given role, or somehow adding resource permissions to a given role without authorization, while PMC involves a complete bypass of security controls meant to enforce permissions. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access.  [src: https://en.wikipedia.org/wiki/Privilege_escalation] |\n| Non-XXE SSRF | In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.[src:https://www.owasp.org/index.php/Server_Side_Request_Forgery] |\n| Insecure Direct Object Reference | IDOR occurs when unvalidated user-supplied input is submitted and direct access to the object requested is provided. Vulnerability reports for IDOR are valid when the result is unauthorized information disclosure, modification or destruction of data, or performing a function outside of the limits of the current user. |\n| CRLF injection/HTTP response splitting  | HTTP response splitting occurs when data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. [src: https://www.owasp.org/index.php/HTTP_Response_Splitting] |\n| Circumvention of our Platform’s Permission Model | Permission Model Circumvention involves a complete bypass of security controls meant to enforce permissions. An example of PMC involves an insecurely configured system in which an API gateway fronts for several servers and implements authentication/authorization. The configuration is such that the URI to the backend servers can be identified and they are directly accessible without any additional authentication or authorization checks..While there is an authX model in place, it was trivially circumventable. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access. |\n| Cross-Site Scripting (excluding self-XSS) | CWE-80:  Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. [src:https://en.wikipedia.org/wiki/Cross-site_scripting] |\n| Cross-Site Request Forgery (CSRF) on critical actions | CWE-352:  Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.  [src: https://en.wikipedia.org/wiki/Cross-site_request_forgery] |\n| Insufficiently Protected Credentials / Credential Exposure | CWE-522:  CWE-522: Within the context of the Salesforce/HackerOne Bug Bounty program, credential exposure involves finding, or gaining access to a user or system credentials which are not meant to be public. An example of IPC would be finding a Github or other repo containing configuration files that contain usernames, passwords, API keys, private keys, etc. Another example is an exposure of a single user's credentials on the querystring, in cookies, or in other HTTP headers. |\n| Insecure/Open Redirect | CWE-601:  An HTTP parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. |\n| DNS Hijacking / Subdomain Takeover | DNS hijacking or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries.The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.  [src: https://en.wikipedia.org/wiki/DNS_hijacking] [src: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers] |\n| Configuration/Stats//Log File Exposure | CWE-532 Information Exposure Through Log Files. CWE-200: Information Exposure. Any instance in which log files or server/application configuration files are accessible when they are not meant to be. |\n| Documentation Bug | Any instance in which, from a strictly security-based perspective, the published documentation is incorrect with regard to the behavior of the product. | \n\n\nNon-Qualifying Vulnerabilities (Out of Scope)\n\n\nThe following types of issues are *specifically excluded* from our Bug Bounty Program:\n* CSRF-able actions that do not require authentication (or a session) to exploit or CSRF issues which have no security impact to Slack.\n\n*Commerce Cloud Specific*\n\n* XSS that is stored in Business Manager and is reflected in the storefront / executed in a Storefront context.\n* Admin to Admin or Admin to User XSS. In these cases, a higher privileged user is attempting to attack the lower privileged user. As an admin, such script execution is considered a feature due to the nature of the platform.\n* CSRF in Storefront\n* CSRF that can only be used to make modifications on the file system\n* Session Fixation inside of Storefront\n* XSS in the following areas: HTML Editor and file upload\n* Login Page / Forgot Password Page Account Brute force or account lockout not enforced\n* Submissions regarding product deficiencies, as opposed to exploitable vulnerabilities\n\n*Other Clouds and Services (Including Commerce Cloud)*\n\n* Access control to objects and fields in Salesforce are done through permission set or profile in setup tree. If that permission or profile in the setup tree is not respected, only then it is considered as an access control issue. Please check all permissions \u0026 profiles for that particular user before filling access control bugs.\n* HTML and Link injections\n* Issues related to \"Editable Github Wiki Pages\"\n* Issues related to Salesforce *Partner* User Credential Disclosure in public code repositories such as GitHub. *Please note that this type of activity is explicitly excluded by the Conduct Guidelines in this policy.*\n* TOCTOU bugs involving platform permission changes. For example; User A has an active session, Admin reduces or increases permissions for User A, User A permissions do not change until User A logs out and back in. This is currently WAD on Salesforce platforms.\n* Invalid links from any Salesforce site to any social media site in which a claim of \"account takeover\" or \"possible phishing attacks\" are the basis for the report.\n* Bugs in content/services that are not owned/operated by Salesforce\n* Vulnerabilities affecting users of outdated or unsupported browsers or platforms\n* Vulnerabilities that have already been addressed in a product update regardless of whether the update has been applied to the publicly available research machines\n* Subdomain takeovers for out of scope domains\n* Self-XSS or XSS bugs requiring an unlikely amount of user interaction\n* XSS in our content sandbox under .content.force.com (http://content.force.com/)\n\n- XSS under \\.sitepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.livepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.visual.force.com (with the exception of Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n\n* XSS in custom apps under .force.com (with the exception of lightning.force.com and Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n\n- Bugs categorized as P3 (low risk)\n- SalesforceDX: Attacks by a root user against another user on the same machine\n- SalesforceDX: Attacks by a user on the same user\n- CSRF on forms that are available to anonymous users (e.g. web2lead contact form)\n- Clickjacking and issues only exploitable through clickjacking\n- Descriptive error messages (e.g. Stack Traces, application or server errors)\n- HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n- Fingerprinting / banner disclosure on common/public services.\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Scripting or other automation and brute-forcing of intended functionality\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n- Lack of Secure and HTTPOnly cookie flags\n- Content spoofing (text injection) or IDN homograph attacks\n- Tabnabbing \n- Email configuration issues (SPF, DKIM, DMARC)\n- Weak Captcha / Captcha Bypass\n- Forced Login / Logout CSRF\n- Account lockout, Login or Forgot Password page brute force\n- Password complexity or account recovery policies\n- Username / email enumeration (brute force)\n- HTTPS Mixed Content\n- Missing HTTP security headers, specifically: Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy.\n- OPTIONS HTTP method enabled\n- Known SSL issues (e.g. attacks such as BEAST, BREACH, POODLE, TLS Renegotiation)\n- SSL Forward Secrecy or HSTS not enabled\n- Weak SSL/TLS Cipher Suites\n- CSV Excel Formula injection\n- Issues related to networking protocols or industry standards not controlled by Salesforce\n- Sending vulnerability reports using automated tools without validation\n- Use of a known-vulnerable library without evidence of exploitability\n- Attacks requiring physical access to a user's unlocked device\n- Reports of spam, phishing or security best practices\n- Reflected XSS involving Adobe Flash files (.swf)\n\n*If you are unsure whether a bug or issue that you discover in a participating service is a non-qualifying vulnerability, please email us at \u003cbugbountymanager@salesforce.com\u003e*\n\n\n_Intellectual Property_\n\n\nParticipating in the Bug Bounty Program does not grant to you or any other third party any rights to any Slack or Salesforce intellectual property, product or service. All rights not otherwise granted herein are expressly reserved. Whether or not we grant you a reward, you hereby assign to Salesforce all right, title and interest (including all intellectual property rights), in the contents of all vulnerability reports that you submit to Salesforce. \n\nBy participating in the Bug Bounty Program, you represent that you have the right to assign all such right, title and interest to us and that your participation in the Bug Bounty Program and assignment of such right, title and interest will not breach any agreement you may have with a third party (e.g. your employer).\n\n\n_Other Terms and Conditions_\n\n\nSalesforce pledges not to pursue a civil action or initiate a complaint to law enforcement against researchers for security research and vulnerability disclosure activities conducted in accordance with this Policy. We consider security research and vulnerability disclosure activities conducted in accordance with this Policy “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA and applicable anti-hacking laws such as Cal. Penal Code 502(c). We waive any DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy.\n\nBy participating in the Bug Bounty Program, you agree to be bound by these rules. These policies will apply to you in addition to, and will not replace, any other terms and conditions that are imposed by HackerOne.\n\n- Your participation in the Bug Bounty Program does not create any kind of employment relationship or partnership between you and Salesforce. You must not hold yourself out as a Salesforce employee or as someone in any way affiliated with Salesforce.\n- You must comply with all applicable laws in connection with your participation in this program. \n- You are responsible for any applicable taxes associated with any reward you receive. \n- Vulnerability reports received prior to the Bug Bounty Program launch are not eligible for rewards and may not be re-submitted for a reward.\n- You will not use any of our trademarks, service marks and logos.\n- We may modify this Policy at any time by posting an updated version of this document.\n- We may terminate this Bug Bounty Program at any time without notice. \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":[],"timestamp":"2025-01-28T16:05:18.170Z"},{"id":3686835,"new_policy":"## Slack Technologies, LLC, a Salesforce company\n\nOver _$12M_ in bounties awarded across all our H1 Bug Bounty programs since 2015!\n\n\nAt Slack, a Salesforce company, Trust is our #1 value and we take the protection of our customers' data very seriously. As a result, we encourage responsible reporting and disclosure of any vulnerabilities that may be found on our websites, APIs, or applications. \n\nSlack is committed to working with security researchers to verify and address any potential vulnerabilities that are reported to us. If you want to help us make our products safer with the possibility of a reward in the process, you are in the right place!\n\nPlease review these terms before you test and/or report a vulnerability. Slack pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.\n\nEligibility for the Bug Bounty Program \n\n\nUnder our Bug Bounty Program, qualified individuals are encouraged to submit bug reports that detail existing vulnerabilities in certain in-scope Salesforce products and services. In certain circumstances, Salesforce may grant monetary rewards to those who submit vulnerability reports.\n\nWe are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Slack. However, only those researchers that meet the following criteria may be eligible to receive a reward. Some of the requirements to participate in the Bug Bounty Program include:\n\n\n* You must be the first reporter of a vulnerability associated with a participating service (we will also not reward for a known vulnerability which we are actively fixing)\n* You must have personally discovered the vulnerability and you may not report a vulnerability that was discovered by another person (including, and especially, someone who does not qualify to participate in the Bug Bounty Program)\n* You must not be employed by Slack, Salesforce, its subsidiaries, or any related entities, currently or in the last 12 months.\n* You must comply with this Policy when discovering the vulnerability and submitting the vulnerability report\n* Slack or H1 can’t be legally prohibited from rewarding you for any reason\n* Non-automated testing is allowed on production Slack infrastructure, preferably using dedicated test teams. Any testing for cross-team vulnerabilities should be conducted using dedicated teams created and owned by the researcher.\n\nConduct Guidelines\n\n\nWhile we encourage you to discover and report to us any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited and will result in disqualification from the Bug Bounty Program:\n\n\n* Disclosing any vulnerabilities or suspected vulnerabilities you discover to any other person without explicit Salesforce authorization\n* Disclosing the contents of any submission to our program without explicit Slack authorization\n* Accessing private information of any person stored on a Slack product or service – You must use test accounts\n* Accessing sensitive information (e.g., credentials)\n* Performing actions that may negatively affect Salesforce system performance or its users (e.g. Spam, Phishing, Brute force, Distributed Denial of Service (DDoS))\n* Conducting any kind of physical attack on Slack personnel, property or data centers\n* Social engineering any Slack employee or contractor\n* Conduct vulnerability testing of participating services using anything other than test accounts (e.g. Developer or Trial Edition instances)\n* Exfiltrating data. Please test only the minimum necessary to validate a vulnerability (we can verify if data exfiltration would be possible from a vulnerability, and will reward with the impact in mind)\n* Violating any laws or breaching any agreements in order to discover vulnerabilities\n\nIf you are testing a publicly viewable area of Slack (eg. https://success.salesforce.com), please remove any test posts or accounts when you are done and refrain from engaging with actual users.\n\n\nOur Commitment to Researchers\n\n\nIf you submit a vulnerability report, the Salesforce security team and associated development organizations will use reasonable efforts to:\n\n\n\n* Respond in a timely manner, acknowledging receipt of your vulnerability report.\n* Investigate and consider your vulnerability report for eligibility under our Bug Bounty Program within 30 days of submission or less.\n* Notify you when the remediation or other action regarding the vulnerability has been implemented. \n\nSlack Products/Services In Scope for H1 Security Researchers\n\nThe Bug Bounty Program is limited to Slack products as specified within the *scope* section in HackerOne.\n\n\n\nQualifying Vulnerabilities \u0026 Bounties (In Scope)\n\n\nThe decision to grant a reward for a vulnerability report, and the value of a reward (if any), is entirely within Salesforce’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the *impact and severity* of the reported vulnerability. \n\n\n* You will qualify for consideration for a reward only if you are the first person to responsibly disclose an unknown vulnerability to us in accordance with these policies. The determination of whether you are the first person is solely within our responsibility. Vulnerabilities must also be relevant, exploitable, and well-documented in the vulnerability report. We are more likely to grant a reward if the vulnerability is specific, fixable and not currently exploited against us or our customers. \n\nOur target reward range for different types of vulnerabilities within the published scope. Additional bounty may be awarded on top of these base amounts, as determined by the Bug Bounty Management team.\n\n\n*Vulnerability Severity Definitions*\n\nThe following vulnerability severity definitions are based on internal Salesforce documentation. These definitional are a work in progress. The goal of adding these definitions to our policy is to: \n\n* Allow more efficient report triage\n* Align directly with internal Salesforce vulnerability ranking definitions\n* Remove ambiguity and subjective assignment of severity\n* Promote fair bounty payments\n* Promote researcher satisfaction\n\nIf you have feedback and/or suggestions to help us make these more clear and useful, please email your ideas to bugbountymanager@salesforce.com\n\n*Critical*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that can compromise the confidentiality, integrity, or availability of production and corporate resources and/or data with limited exploitation difficulty and/or attacker skill.\n    * Vulnerabilities that could be easily exploited by a remote or unauthenticated attacker and lead to system compromise and/or exposure of highly sensitive or customer data of any kind without requiring user interaction. \n    * Exploitation of a vulnerability that results in a root-level compromise of servers or infrastructure devices.\n* Examples include, but are not limited to:\n    * External facing remote arbitrary code execution without mitigating circumstances. \n    * External facing SQL injection. \n    * External facing unintended single tenant or cross tenant information disclosure and/or multi-tenancy break\n    * Authentication flaws resulting in arbitrary account compromise.\n    * Session management flaws leading to arbitrary account compromise. \n    * External facing credential leaks and default credential usage resulting in access to production systems containing customer data.\n    * Client and server software and system s susceptible to publicly disclosed and exploited vulnerability.\n    * Susceptibility to an external, simply executed, single actor, logic-based attacks resulting in a service outage of one or more critical systems/products.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Critical (In a small subset of cases)\n    * CVSSv3 Temporal Score: 9-10\n    * Qualys Severity 5\n    * nCircle: 1000+ (Based on risk )\n    * PCI Violating Vulnerability: Yes\n    * AppDetective: High (Based on risk )\n    * Whitehat: Urgent\n\n*High*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that can compromise the confidentiality, integrity, or availability of production and corporate resources and data.\n    * Vulnerabilities that could be easily exploited by an internal and/or external, authenticated/unauthenticated attacker and lead to system compromise and/or exposure of highly sensitive or customer data without requiring user interaction.\n    * Vulnerabilities that allow local users to gain increased privileges.\n    * Vulnerabilities that allow unauthenticated remote users to view sensitive information.\n    * Susceptibility to an external, simply executed, single actor, logic-based attacks resulting in significant performance degradation of one or more critical systems/products.\n* Examples include, but are not limited to:\n    * Privilege Escalation  \n    * External facing Persistent/Stored Cross-Site Scripting (XSS).\n    * External facing Cross-Site Request Forgery (CSRF) exposure on sensitive or critical functions.\n    * External facing stack traces containing sensitive information exposed to clients.\n    * Internal network/system use of weak cryptography that is practically exploitable in a real kill chain without nation-state resources.\n    * Internal network/system remote arbitrary code execution without mitigating circumstances.\n    * Internal network/system command or SQL injection without mitigating circumstances.\n    * Internal network/system exposure of sensitive information.\n    * Internal network/system use of default or weak credentials.\n    * Client/Server software and/or systems susceptible to publicly disclosed vulnerability.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Critical/Severe\n    * CVSSv3 Temporal Score: 7 - 8.93\n    * Qualys: Severity 44\n    * nCircle:1000 +\n    * PCI Violating Vuln: Yes\n    * AppDetective: High\n    * Whitehat: Critical\n\n*Medium*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. \n    * Vulnerabilities that could have had a critical or high impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.\n    * Susceptibility to external, simply executed, single actor, logic-based attacks resulting in some measurable performance degradation of one or more critical systems/products.\n* Examples include, but are not limited to:\n    * External unintended internal information disclosure.\n    * Internal network/application Cross-Site Scripting (XSS).\n    * Internal network/application Cross-Site Request Forgery (CSRF).\n    * Internal use of weak cryptography that is practically exploitable in a real kill chain with nation-state resources.\n    * Usage of EoL operating systems or software.\n    * External facing content spoofing.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Moderate\n    * CVSSv3 Temporal Score: 4 - 6.93\n    * Qualys: Severity 34. \n    * nCircle: 500 - 999.5. \n    * PCI Violating Vuln: No\n    * AppDetective: Medium\n    * Whitehat: High\n\n*Low*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that may be more difficult to exploit but could lead to minimal compromise of the confidentiality, integrity, or availability of resources under unlikely circumstances.\n    * These types of vulnerabilities require unlikely circumstances to be able to be exploited, or where a successful exploit would have minimal consequences.\n    * Susceptibility to external, simply executed, single actor, logic-based attacks resulting in minor performance degradation of one or more critical systems/products. \n* Examples include, but are not limited to:\n    * XSS from an authenticated customer admin\n    * Internal default pages or content without vulnerabilities such as an Apache server-status page enabled, allowing anyone browsing it to see the information of the server, as well as any request currently being made.\n    * Exposure of server config information\n    * Use of weak cryptography that is not practically exploitable in a real kill-chain.\n    * Documentation bugs\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Moderate (Informational in nature)\n    * CVSSv3 Temporal Score: 0.1 -3.93\n    * Qualys: Severity 24\n    * nCircle: 1 -499.5.\n    * PCI Violating Vuln: No\n    * AppDetective: Low 7\n    * Whitehat: Low\n\n*Qualifying Vulnerability Descriptions*\n\n\n| Category | Description |\n| --- | --- |\n| Remote Code Execution | CWE-94: AKA \"Arbitrary Code Execution\".  Describes a security bug that allows an attacker to execute arbitrary commands or code on a target machine or in a target process. The exploit PoC may include many other vulnerability types, but ultimately the result is p0wnage of the server(s) and/or environment.  [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Disclosure of Credit Card data | CWE-359:  This is self-explanatory. Any security bug which allows disclosure of credit card information to an unauthorized user or system qualifies as Disclosure of Credit Card Data |\n| SQL Injection | CWE-1027:  SQL injection is a code injection technique in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Unrestricted XXE / File System Access | CWE-611:  External XML Entity Injection (XXE) is a specific type of Server Side Request Forgery(SSRF) which affects an XML processing engine server-side on a target. Specifically, blind XXE is when the results are either error-based or cause 3rd party interaction with services such as HTTP, FTP \u0026 DNS. An XXE attack typically occurs when XML input containing a reference to an external entity is processed by a weakly configured parser. An attacker can leverage an XXE attack to access sensitive data and read local or remote files. In a similar manner to SSRF, an attacker could introduce malicious code through Remote Code Execution (RCE).  [scr: https://blog.zsec.uk/out-of-band-xxe-2/]  [src: https://chris-young.net/2018/04/13/xxe-xml-external-entity/] |\n| Significant Authentication Bypass | CWE-305:  Authentication bypass is a vulnerability that allows an attacker access to credential protected resources without first acquiring valid credentials. Examples of this vulnerability include:* SQL injection during login to bypasses credential authentication* Direct access to resources normally beyond an authentication mechanism, such as a login screen, which do not independently validate the users authenticated session.* Failure to enumerate and enforce the systems' access policy. * A weak authentication system that allows a valid identity to be forged. | \n| Significant Authorization Bypass | CWE-285:  Authorization is the concept of allowing access to resources only to those permitted to use them. Vulnerabilities that bypass authorization checks may allow access to protected resources beyond what was intended by the system. Examples of authorization bypass include Insecure Direct Object Reference and Session Token Alteration. In each of these examples, the system trusts the users' requests because of improper or insecure implementation. |\n| Cross Instance Privilege Escalation | Salesforce is a multi-tenant platform in which \"instances\" are created for each Org. A cross-instance privilege escalation involves some user in instance A having access to data in instance B without proper authorization. |\n| Denial of Service | Susceptibility to an external, simply executed, single actor, logic-based attack resulting in a service outage or significant performance degradation of one or more critical systems/products  |\n| Disclosure of Personal Identifiable Information | CWE-200:  Personally identifiable information, or PII, is any data that could potentially be used to identify a particular person. As it relates to Salesforce, PII Disclosure bugs involve PII data stored within any in-scope platforms, excluding Salesforce Employee data such as Name and Contact information.  [src: https://www.lifelock.com/learn-identity-theft-resources-what-is-personally-identifiable-information.html] |\n| Salesforce Platform Misconfiguration and/or Custom APEX Vulnerabilities (Salesforce Owned/Controlled) | The Salesforce Platform is highly configurable, customizable, and supports custom code in the form of APEX code, Visualforce pages, etc. It is therefore capable of being misconfigured in such a way as to leak information or to otherwise be insecure. This category of vulnerability is specific to Salesforce owned and operated sites, NOT Salesforce customer-owned and operated Salesforce instances. If you identify a configuration vulnerability in a customer site please report it to that company via their Bug Bounty program or their security@\u003csome company dot com\u003e email address. There is no guarantee that the customer will respond to your email or bug submission, and it is out of Salesforce control. Please do not expect Salesforce to handle reports of customer misconfiguration.|\n| Privilege Escalation / Improper Access Control | Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in a software application to gain elevated access to resources that are normally protected from an application or user. The result is that a user with more privileges than intended by the application developer or system administrator can perform unauthorized actions. Note that Privilege Escalation is different from Permission Model Circumvention in that PE involves accessing functionality beyond that assigned to a given role, or somehow adding resource permissions to a given role without authorization, while PMC involves a complete bypass of security controls meant to enforce permissions. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access.  [src: https://en.wikipedia.org/wiki/Privilege_escalation] |\n| Non-XXE SSRF | In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.[src:https://www.owasp.org/index.php/Server_Side_Request_Forgery] |\n| Insecure Direct Object Reference | IDOR occurs when unvalidated user-supplied input is submitted and direct access to the object requested is provided. Vulnerability reports for IDOR are valid when the result is unauthorized information disclosure, modification or destruction of data, or performing a function outside of the limits of the current user. |\n| CRLF injection/HTTP response splitting  | HTTP response splitting occurs when data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. [src: https://www.owasp.org/index.php/HTTP_Response_Splitting] |\n| Circumvention of our Platform’s Permission Model | Permission Model Circumvention involves a complete bypass of security controls meant to enforce permissions. An example of PMC involves an insecurely configured system in which an API gateway fronts for several servers and implements authentication/authorization. The configuration is such that the URI to the backend servers can be identified and they are directly accessible without any additional authentication or authorization checks..While there is an authX model in place, it was trivially circumventable. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access. |\n| Cross-Site Scripting (excluding self-XSS) | CWE-80:  Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. [src:https://en.wikipedia.org/wiki/Cross-site_scripting] |\n| Cross-Site Request Forgery (CSRF) on critical actions | CWE-352:  Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.  [src: https://en.wikipedia.org/wiki/Cross-site_request_forgery] |\n| Insufficiently Protected Credentials / Credential Exposure | CWE-522:  CWE-522: Within the context of the Salesforce/HackerOne Bug Bounty program, credential exposure involves finding, or gaining access to a user or system credentials which are not meant to be public. An example of IPC would be finding a Github or other repo containing configuration files that contain usernames, passwords, API keys, private keys, etc. Another example is an exposure of a single user's credentials on the querystring, in cookies, or in other HTTP headers. |\n| Insecure/Open Redirect | CWE-601:  An HTTP parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. |\n| DNS Hijacking / Subdomain Takeover | DNS hijacking or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries.The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.  [src: https://en.wikipedia.org/wiki/DNS_hijacking] [src: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers] |\n| Configuration/Stats//Log File Exposure | CWE-532 Information Exposure Through Log Files. CWE-200: Information Exposure. Any instance in which log files or server/application configuration files are accessible when they are not meant to be. |\n| Documentation Bug | Any instance in which, from a strictly security-based perspective, the published documentation is incorrect with regard to the behavior of the product. | \n\n\nNon-Qualifying Vulnerabilities (Out of Scope)\n\n\nThe following types of issues are *specifically excluded* from our Bug Bounty Program:\n* CSRF-able actions that do not require authentication (or a session) to exploit or CSRF issues which have no security impact to Slack.\n\n*Commerce Cloud Specific*\n\n* XSS that is stored in Business Manager and is reflected in the storefront / executed in a Storefront context.\n* Admin to Admin or Admin to User XSS. In these cases, a higher privileged user is attempting to attack the lower privileged user. As an admin, such script execution is considered a feature due to the nature of the platform.\n* CSRF in Storefront\n* CSRF that can only be used to make modifications on the file system\n* Session Fixation inside of Storefront\n* XSS in the following areas: HTML Editor and file upload\n* Login Page / Forgot Password Page Account Brute force or account lockout not enforced\n* Submissions regarding product deficiencies, as opposed to exploitable vulnerabilities\n\n*Other Clouds and Services (Including Commerce Cloud)*\n\n* Access control to objects and fields in Salesforce are done through permission set or profile in setup tree. If that permission or profile in the setup tree is not respected, only then it is considered as an access control issue. Please check all permissions \u0026 profiles for that particular user before filling access control bugs.\n* HTML and Link injections\n* Issues related to \"Editable Github Wiki Pages\"\n* Issues related to Salesforce *Partner* User Credential Disclosure in public code repositories such as GitHub. *Please note that this type of activity is explicitly excluded by the Conduct Guidelines in this policy.*\n* TOCTOU bugs involving platform permission changes. For example; User A has an active session, Admin reduces or increases permissions for User A, User A permissions do not change until User A logs out and back in. This is currently WAD on Salesforce platforms.\n* Invalid links from any Salesforce site to any social media site in which a claim of \"account takeover\" or \"possible phishing attacks\" are the basis for the report.\n* Bugs in content/services that are not owned/operated by Salesforce\n* Vulnerabilities affecting users of outdated or unsupported browsers or platforms\n* Vulnerabilities that have already been addressed in a product update regardless of whether the update has been applied to the publicly available research machines\n* Subdomain takeovers for out of scope domains\n* Self-XSS or XSS bugs requiring an unlikely amount of user interaction\n* XSS in our content sandbox under .content.force.com (http://content.force.com/)\n\n- XSS under \\.sitepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.livepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.visual.force.com (with the exception of Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n\n* XSS in custom apps under .force.com (with the exception of lightning.force.com and Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n\n- Bugs categorized as P3 (low risk)\n- SalesforceDX: Attacks by a root user against another user on the same machine\n- SalesforceDX: Attacks by a user on the same user\n- CSRF on forms that are available to anonymous users (e.g. web2lead contact form)\n- Clickjacking and issues only exploitable through clickjacking\n- Descriptive error messages (e.g. Stack Traces, application or server errors)\n- HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n- Fingerprinting / banner disclosure on common/public services.\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Scripting or other automation and brute-forcing of intended functionality\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n- Lack of Secure and HTTPOnly cookie flags\n- Content spoofing (text injection) or IDN homograph attacks\n- Tabnabbing \n- Email configuration issues (SPF, DKIM, DMARC)\n- Weak Captcha / Captcha Bypass\n- Forced Login / Logout CSRF\n- Account lockout, Login or Forgot Password page brute force\n- Password complexity or account recovery policies\n- Username / email enumeration (brute force)\n- HTTPS Mixed Content\n- Missing HTTP security headers, specifically: Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy.\n- OPTIONS HTTP method enabled\n- Known SSL issues (e.g. attacks such as BEAST, BREACH, POODLE, TLS Renegotiation)\n- SSL Forward Secrecy or HSTS not enabled\n- Weak SSL/TLS Cipher Suites\n- CSV Excel Formula injection\n- Issues related to networking protocols or industry standards not controlled by Salesforce\n- Sending vulnerability reports using automated tools without validation\n- Use of a known-vulnerable library without evidence of exploitability\n- Attacks requiring physical access to a user's unlocked device\n- Reports of spam, phishing or security best practices\n- Reflected XSS involving Adobe Flash files (.swf)\n\n*If you are unsure whether a bug or issue that you discover in a participating service is a non-qualifying vulnerability, please email us at \u003cbugbountymanager@salesforce.com\u003e*\n\n\n_Intellectual Property_\n\n\nParticipating in the Bug Bounty Program does not grant to you or any other third party any rights to any Slack or Salesforce intellectual property, product or service. All rights not otherwise granted herein are expressly reserved. Whether or not we grant you a reward, you hereby assign to Salesforce all right, title and interest (including all intellectual property rights), in the contents of all vulnerability reports that you submit to Salesforce. \n\nBy participating in the Bug Bounty Program, you represent that you have the right to assign all such right, title and interest to us and that your participation in the Bug Bounty Program and assignment of such right, title and interest will not breach any agreement you may have with a third party (e.g. your employer).\n\n\n_Other Terms and Conditions_\n\n\nSalesforce pledges not to pursue a civil action or initiate a complaint to law enforcement against researchers for security research and vulnerability disclosure activities conducted in accordance with this Policy. We consider security research and vulnerability disclosure activities conducted in accordance with this Policy “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA and applicable anti-hacking laws such as Cal. Penal Code 502(c). We waive any DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy.\n\nBy participating in the Bug Bounty Program, you agree to be bound by these rules. These policies will apply to you in addition to, and will not replace, any other terms and conditions that are imposed by HackerOne.\n\n- Your participation in the Bug Bounty Program does not create any kind of employment relationship or partnership between you and Salesforce. You must not hold yourself out as a Salesforce employee or as someone in any way affiliated with Salesforce.\n- You must comply with all applicable laws in connection with your participation in this program. \n- You are responsible for any applicable taxes associated with any reward you receive. \n- Vulnerability reports received prior to the Bug Bounty Program launch are not eligible for rewards and may not be re-submitted for a reward.\n- You will not use any of our trademarks, service marks and logos.\n- We may modify this Policy at any time by posting an updated version of this document.\n- We may terminate this Bug Bounty Program at any time without notice. \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":[],"timestamp":"2023-05-03T14:10:48.388Z"},{"id":3680751,"new_policy":"## Slack Technologies, LLC, a Salesforce company\n\nOver _$12M_ in bounties awarded across all our H1 Bug Bounty programs since 2015!\n\n\nAt Slack, a Salesforce company, Trust is our #1 value and we take the protection of our customers' data very seriously. As a result, we encourage responsible reporting and disclosure of any vulnerabilities that may be found on our websites, APIs, or applications. \n\nSlack is committed to working with security researchers to verify and address any potential vulnerabilities that are reported to us. If you want to help us make our products safer with the possibility of a reward in the process, you are in the right place!\n\nPlease review these terms before you test and/or report a vulnerability. Slack pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.\n\nEligibility for the Bug Bounty Program \n\n\nUnder our Bug Bounty Program, qualified individuals are encouraged to submit bug reports that detail existing vulnerabilities in certain in-scope Salesforce products and services. In certain circumstances, Salesforce may grant monetary rewards to those who submit vulnerability reports.\n\nWe are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Slack. However, only those researchers that meet the following criteria may be eligible to receive a reward. Some of the requirements to participate in the Bug Bounty Program include:\n\n\n* You must be the first reporter of a vulnerability associated with a participating service (we will also not reward for a known vulnerability which we are actively fixing)\n* You must have personally discovered the vulnerability and you may not report a vulnerability that was discovered by another person (including, and especially, someone who does not qualify to participate in the Bug Bounty Program)\n* You must not be employed by Slack, Salesforce, its subsidiaries, or any related entities, currently or in the last 12 months.\n* You must comply with this Policy when discovering the vulnerability and submitting the vulnerability report\n* Slack or H1 can’t be legally prohibited from rewarding you for any reason\n* Non-automated testing is allowed on production Slack infrastructure, preferably using dedicated test teams. Any testing for cross-team vulnerabilities should be conducted using dedicated teams created and owned by the researcher.\n\nConduct Guidelines\n\n\nWhile we encourage you to discover and report to us any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited and will result in disqualification from the Bug Bounty Program:\n\n\n* Disclosing any vulnerabilities or suspected vulnerabilities you discover to any other person without explicit Salesforce authorization\n* Disclosing the contents of any submission to our program without explicit Slack authorization\n* Accessing private information of any person stored on a Slack product or service – You must use test accounts\n* Accessing sensitive information (e.g., credentials)\n* Performing actions that may negatively affect Salesforce system performance or its users (e.g. Spam, Phishing, Brute force, Distributed Denial of Service (DDoS))\n* Conducting any kind of physical attack on Slack personnel, property or data centers\n* Social engineering any Slack employee or contractor\n* Conduct vulnerability testing of participating services using anything other than test accounts (e.g. Developer or Trial Edition instances)\n* Exfiltrating data. Please test only the minimum necessary to validate a vulnerability (we can verify if data exfiltration would be possible from a vulnerability, and will reward with the impact in mind)\n* Violating any laws or breaching any agreements in order to discover vulnerabilities\n\nIf you are testing a publicly viewable area of Slack (eg. https://success.salesforce.com), please remove any test posts or accounts when you are done and refrain from engaging with actual users.\n\n\nOur Commitment to Researchers\n\n\nIf you submit a vulnerability report, the Salesforce security team and associated development organizations will use reasonable efforts to:\n\n\n\n* Respond in a timely manner, acknowledging receipt of your vulnerability report.\n* Investigate and consider your vulnerability report for eligibility under our Bug Bounty Program within 30 days of submission or less.\n* Notify you when the remediation or other action regarding the vulnerability has been implemented. \n\nSlack Products/Services In Scope for H1 Security Researchers\n\nThe Bug Bounty Program is limited to Slack products as specified within the *scope* section in HackerOne.\n\n\n\nQualifying Vulnerabilities \u0026 Bounties (In Scope)\n\n\nThe decision to grant a reward for a vulnerability report, and the value of a reward (if any), is entirely within Salesforce’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the *impact and severity* of the reported vulnerability. \n\n\n* You will qualify for consideration for a reward only if you are the first person to responsibly disclose an unknown vulnerability to us in accordance with these policies. The determination of whether you are the first person is solely within our responsibility. Vulnerabilities must also be relevant, exploitable, and well-documented in the vulnerability report. We are more likely to grant a reward if the vulnerability is specific, fixable and not currently exploited against us or our customers. \n\nOur target reward range for different types of vulnerabilities within the published scope. Additional bounty may be awarded on top of these base amounts, as determined by the Bug Bounty Management team.\n\n\n*Vulnerability Severity Definitions*\n\nThe following vulnerability severity definitions are based on internal Salesforce documentation. These definitional are a work in progress. The goal of adding these definitions to our policy is to: \n\n* Allow more efficient report triage\n* Align directly with internal Salesforce vulnerability ranking definitions\n* Remove ambiguity and subjective assignment of severity\n* Promote fair bounty payments\n* Promote researcher satisfaction\n\nIf you have feedback and/or suggestions to help us make these more clear and useful, please email your ideas to bugbountymanager@salesforce.com\n\n*Critical*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that can compromise the confidentiality, integrity, or availability of production and corporate resources and/or data with limited exploitation difficulty and/or attacker skill.\n    * Vulnerabilities that could be easily exploited by a remote or unauthenticated attacker and lead to system compromise and/or exposure of highly sensitive or customer data of any kind without requiring user interaction. \n    * Exploitation of a vulnerability that results in a root-level compromise of servers or infrastructure devices.\n* Examples include, but are not limited to:\n    * External facing remote arbitrary code execution without mitigating circumstances. \n    * External facing SQL injection. \n    * External facing unintended single tenant or cross tenant information disclosure and/or multi-tenancy break\n    * Authentication flaws resulting in arbitrary account compromise.\n    * Session management flaws leading to arbitrary account compromise. \n    * External facing credential leaks and default credential usage resulting in access to production systems containing customer data.\n    * Client and server software and system s susceptible to publicly disclosed and exploited vulnerability.\n    * Susceptibility to an external, simply executed, single actor, logic-based attacks resulting in a service outage of one or more critical systems/products.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Critical (In a small subset of cases)\n    * CVSSv3 Temporal Score: 9-10\n    * Qualys Severity 5\n    * nCircle: 1000+ (Based on risk )\n    * PCI Violating Vulnerability: Yes\n    * AppDetective: High (Based on risk )\n    * Whitehat: Urgent\n\n*High*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that can compromise the confidentiality, integrity, or availability of production and corporate resources and data.\n    * Vulnerabilities that could be easily exploited by an internal and/or external, authenticated/unauthenticated attacker and lead to system compromise and/or exposure of highly sensitive or customer data without requiring user interaction.\n    * Vulnerabilities that allow local users to gain increased privileges.\n    * Vulnerabilities that allow unauthenticated remote users to view sensitive information.\n    * Susceptibility to an external, simply executed, single actor, logic-based attacks resulting in significant performance degradation of one or more critical systems/products.\n* Examples include, but are not limited to:\n    * Privilege Escalation  \n    * External facing Persistent/Stored Cross-Site Scripting (XSS).\n    * External facing Cross-Site Request Forgery (CSRF) exposure on sensitive or critical functions.\n    * External facing stack traces containing sensitive information exposed to clients.\n    * Internal network/system use of weak cryptography that is practically exploitable in a real kill chain without nation-state resources.\n    * Internal network/system remote arbitrary code execution without mitigating circumstances.\n    * Internal network/system command or SQL injection without mitigating circumstances.\n    * Internal network/system exposure of sensitive information.\n    * Internal network/system use of default or weak credentials.\n    * Client/Server software and/or systems susceptible to publicly disclosed vulnerability.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Critical/Severe\n    * CVSSv3 Temporal Score: 7 - 8.93\n    * Qualys: Severity 44\n    * nCircle:1000 +\n    * PCI Violating Vuln: Yes\n    * AppDetective: High\n    * Whitehat: Critical\n\n*Medium*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. \n    * Vulnerabilities that could have had a critical or high impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.\n    * Susceptibility to external, simply executed, single actor, logic-based attacks resulting in some measurable performance degradation of one or more critical systems/products.\n* Examples include, but are not limited to:\n    * External unintended internal information disclosure.\n    * Internal network/application Cross-Site Scripting (XSS).\n    * Internal network/application Cross-Site Request Forgery (CSRF).\n    * Internal use of weak cryptography that is practically exploitable in a real kill chain with nation-state resources.\n    * Usage of EoL operating systems or software.\n    * External facing content spoofing.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Moderate\n    * CVSSv3 Temporal Score: 4 - 6.93\n    * Qualys: Severity 34. \n    * nCircle: 500 - 999.5. \n    * PCI Violating Vuln: No\n    * AppDetective: Medium\n    * Whitehat: High\n\n*Low*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that may be more difficult to exploit but could lead to minimal compromise of the confidentiality, integrity, or availability of resources under unlikely circumstances.\n    * These types of vulnerabilities require unlikely circumstances to be able to be exploited, or where a successful exploit would have minimal consequences.\n    * Susceptibility to external, simply executed, single actor, logic-based attacks resulting in minor performance degradation of one or more critical systems/products. \n* Examples include, but are not limited to:\n    * XSS from an authenticated customer admin\n    * Internal default pages or content without vulnerabilities such as an Apache server-status page enabled, allowing anyone browsing it to see the information of the server, as well as any request currently being made.\n    * Exposure of server config information\n    * Use of weak cryptography that is not practically exploitable in a real kill-chain.\n    * Documentation bugs\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Moderate (Informational in nature)\n    * CVSSv3 Temporal Score: 0.1 -3.93\n    * Qualys: Severity 24\n    * nCircle: 1 -499.5.\n    * PCI Violating Vuln: No\n    * AppDetective: Low 7\n    * Whitehat: Low\n\n*Qualifying Vulnerability Descriptions*\n\n\n| Category | Description |\n| --- | --- |\n| Remote Code Execution | CWE-94: AKA \"Arbitrary Code Execution\".  Describes a security bug that allows an attacker to execute arbitrary commands or code on a target machine or in a target process. The exploit PoC may include many other vulnerability types, but ultimately the result is p0wnage of the server(s) and/or environment.  [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Disclosure of Credit Card data | CWE-359:  This is self-explanatory. Any security bug which allows disclosure of credit card information to an unauthorized user or system qualifies as Disclosure of Credit Card Data |\n| SQL Injection | CWE-1027:  SQL injection is a code injection technique in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Unrestricted XXE / File System Access | CWE-611:  External XML Entity Injection (XXE) is a specific type of Server Side Request Forgery(SSRF) which affects an XML processing engine server-side on a target. Specifically, blind XXE is when the results are either error-based or cause 3rd party interaction with services such as HTTP, FTP \u0026 DNS. An XXE attack typically occurs when XML input containing a reference to an external entity is processed by a weakly configured parser. An attacker can leverage an XXE attack to access sensitive data and read local or remote files. In a similar manner to SSRF, an attacker could introduce malicious code through Remote Code Execution (RCE).  [scr: https://blog.zsec.uk/out-of-band-xxe-2/]  [src: https://chris-young.net/2018/04/13/xxe-xml-external-entity/] |\n| Significant Authentication Bypass | CWE-305:  Authentication bypass is a vulnerability that allows an attacker access to credential protected resources without first acquiring valid credentials. Examples of this vulnerability include:* SQL injection during login to bypasses credential authentication* Direct access to resources normally beyond an authentication mechanism, such as a login screen, which do not independently validate the users authenticated session.* Failure to enumerate and enforce the systems' access policy. * A weak authentication system that allows a valid identity to be forged. | \n| Significant Authorization Bypass | CWE-285:  Authorization is the concept of allowing access to resources only to those permitted to use them. Vulnerabilities that bypass authorization checks may allow access to protected resources beyond what was intended by the system. Examples of authorization bypass include Insecure Direct Object Reference and Session Token Alteration. In each of these examples, the system trusts the users' requests because of improper or insecure implementation. |\n| Cross Instance Privilege Escalation | Salesforce is a multi-tenant platform in which \"instances\" are created for each Org. A cross-instance privilege escalation involves some user in instance A having access to data in instance B without proper authorization. |\n| Denial of Service | Susceptibility to an external, simply executed, single actor, logic-based attack resulting in a service outage or significant performance degradation of one or more critical systems/products  |\n| Disclosure of Personal Identifiable Information | CWE-200:  Personally identifiable information, or PII, is any data that could potentially be used to identify a particular person. As it relates to Salesforce, PII Disclosure bugs involve PII data stored within any in-scope platforms, excluding Salesforce Employee data such as Name and Contact information.  [src: https://www.lifelock.com/learn-identity-theft-resources-what-is-personally-identifiable-information.html] |\n| Salesforce Platform Misconfiguration and/or Custom APEX Vulnerabilities (Salesforce Owned/Controlled) | The Salesforce Platform is highly configurable, customizable, and supports custom code in the form of APEX code, Visualforce pages, etc. It is therefore capable of being misconfigured in such a way as to leak information or to otherwise be insecure. This category of vulnerability is specific to Salesforce owned and operated sites, NOT Salesforce customer-owned and operated Salesforce instances. If you identify a configuration vulnerability in a customer site please report it to that company via their Bug Bounty program or their security@\u003csome company dot com\u003e email address. There is no guarantee that the customer will respond to your email or bug submission, and it is out of Salesforce control. Please do not expect Salesforce to handle reports of customer misconfiguration.|\n| Privilege Escalation / Improper Access Control | Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in a software application to gain elevated access to resources that are normally protected from an application or user. The result is that a user with more privileges than intended by the application developer or system administrator can perform unauthorized actions. Note that Privilege Escalation is different from Permission Model Circumvention in that PE involves accessing functionality beyond that assigned to a given role, or somehow adding resource permissions to a given role without authorization, while PMC involves a complete bypass of security controls meant to enforce permissions. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access.  [src: https://en.wikipedia.org/wiki/Privilege_escalation] |\n| Non-XXE SSRF | In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.[src:https://www.owasp.org/index.php/Server_Side_Request_Forgery] |\n| Insecure Direct Object Reference | IDOR occurs when unvalidated user-supplied input is submitted and direct access to the object requested is provided. Vulnerability reports for IDOR are valid when the result is unauthorized information disclosure, modification or destruction of data, or performing a function outside of the limits of the current user. |\n| CRLF injection/HTTP response splitting  | HTTP response splitting occurs when data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. [src: https://www.owasp.org/index.php/HTTP_Response_Splitting] |\n| Circumvention of our Platform’s Permission Model | Permission Model Circumvention involves a complete bypass of security controls meant to enforce permissions. An example of PMC involves an insecurely configured system in which an API gateway fronts for several servers and implements authentication/authorization. The configuration is such that the URI to the backend servers can be identified and they are directly accessible without any additional authentication or authorization checks..While there is an authX model in place, it was trivially circumventable. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access. |\n| Cross-Site Scripting (excluding self-XSS) | CWE-80:  Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. [src:https://en.wikipedia.org/wiki/Cross-site_scripting] |\n| Cross-Site Request Forgery (CSRF) on critical actions | CWE-352:  Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.  [src: https://en.wikipedia.org/wiki/Cross-site_request_forgery] |\n| Insufficiently Protected Credentials / Credential Exposure | CWE-522:  CWE-522: Within the context of the Salesforce/HackerOne Bug Bounty program, credential exposure involves finding, or gaining access to a user or system credentials which are not meant to be public. An example of IPC would be finding a Github or other repo containing configuration files that contain usernames, passwords, API keys, private keys, etc. Another example is an exposure of a single user's credentials on the querystring, in cookies, or in other HTTP headers. |\n| Insecure/Open Redirect | CWE-601:  An HTTP parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. |\n| DNS Hijacking / Subdomain Takeover | DNS hijacking or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries.The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.  [src: https://en.wikipedia.org/wiki/DNS_hijacking] [src: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers] |\n| Configuration/Stats//Log File Exposure | CWE-532 Information Exposure Through Log Files. CWE-200: Information Exposure. Any instance in which log files or server/application configuration files are accessible when they are not meant to be. |\n| Documentation Bug | Any instance in which, from a strictly security-based perspective, the published documentation is incorrect with regard to the behavior of the product. | \n\n\nNon-Qualifying Vulnerabilities (Out of Scope)\n\n\nThe following types of issues are *specifically excluded* from our Bug Bounty Program:\n* CSRF-able actions that do not require authentication (or a session) to exploit or CSRF issues which have no security impact to Slack.\n\n*Commerce Cloud Specific*\n\n* XSS that is stored in Business Manager and is reflected in the storefront / executed in a Storefront context.\n* Admin to Admin or Admin to User XSS. In these cases, a higher privileged user is attempting to attack the lower privileged user. As an admin, such script execution is considered a feature due to the nature of the platform.\n* CSRF in Storefront\n* CSRF that can only be used to make modifications on the file system\n* Session Fixation inside of Storefront\n* XSS in the following areas: HTML Editor and file upload\n* Login Page / Forgot Password Page Account Brute force or account lockout not enforced\n* Submissions regarding product deficiencies, as opposed to exploitable vulnerabilities\n\n*Other Clouds and Services (Including Commerce Cloud)*\n\n* Access control to objects and fields in Salesforce are done through permission set or profile in setup tree. If that permission or profile in the setup tree is not respected, only then it is considered as an access control issue. Please check all permissions \u0026 profiles for that particular user before filling access control bugs.\n* HTML and Link injections\n* Issues related to \"Editable Github Wiki Pages\"\n* Issues related to Salesforce *Partner* User Credential Disclosure in public code repositories such as GitHub. *Please note that this type of activity is explicitly excluded by the Conduct Guidelines in this policy.*\n* TOCTOU bugs involving platform permission changes. For example; User A has an active session, Admin reduces or increases permissions for User A, User A permissions do not change until User A logs out and back in. This is currently WAD on Salesforce platforms.\n* Invalid links from any Salesforce site to any social media site in which a claim of \"account takeover\" or \"possible phishing attacks\" are the basis for the report.\n* Bugs in content/services that are not owned/operated by Salesforce\n* Vulnerabilities affecting users of outdated or unsupported browsers or platforms\n* Vulnerabilities that have already been addressed in a product update regardless of whether the update has been applied to the publicly available research machines\n* Subdomain takeovers for out of scope domains\n* Self-XSS or XSS bugs requiring an unlikely amount of user interaction\n* XSS in our content sandbox under .content.force.com (http://content.force.com/)\n\n- XSS under \\.sitepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.livepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.visual.force.com (with the exception of Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n\n* XSS in custom apps under .force.com (with the exception of lightning.force.com and Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n\n- Bugs categorized as P3 (low risk)\n- SalesforceDX: Attacks by a root user against another user on the same machine\n- SalesforceDX: Attacks by a user on the same user\n- CSRF on forms that are available to anonymous users (e.g. web2lead contact form)\n- Clickjacking and issues only exploitable through clickjacking\n- Descriptive error messages (e.g. Stack Traces, application or server errors)\n- HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n- Fingerprinting / banner disclosure on common/public services.\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Scripting or other automation and brute-forcing of intended functionality\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n- Lack of Secure and HTTPOnly cookie flags\n- Content spoofing (text injection) or IDN homograph attacks\n- Tabnabbing \n- Email configuration issues (SPF, DKIM, DMARC)\n- Weak Captcha / Captcha Bypass\n- Forced Login / Logout CSRF\n- Account lockout, Login or Forgot Password page brute force\n- Password complexity or account recovery policies\n- Username / email enumeration (brute force)\n- HTTPS Mixed Content\n- Missing HTTP security headers, specifically: Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy.\n- OPTIONS HTTP method enabled\n- Known SSL issues (e.g. attacks such as BEAST, BREACH, POODLE, TLS Renegotiation)\n- SSL Forward Secrecy or HSTS not enabled\n- Weak SSL/TLS Cipher Suites\n- CSV Excel Formula injection\n- Issues related to networking protocols or industry standards not controlled by Salesforce\n- Sending vulnerability reports using automated tools without validation\n- Use of a known-vulnerable library without evidence of exploitability\n- Problems related to widely publicized CVE's\n- Attacks requiring physical access to a user's unlocked device\n- Reports of spam, phishing or security best practices\n- Reflected XSS involving Adobe Flash files (.swf)\n\n*If you are unsure whether a bug or issue that you discover in a participating service is a non-qualifying vulnerability, please email us at \u003cbugbountymanager@salesforce.com\u003e*\n\n\n_Intellectual Property_\n\n\nParticipating in the Bug Bounty Program does not grant to you or any other third party any rights to any Slack or Salesforce intellectual property, product or service. All rights not otherwise granted herein are expressly reserved. Whether or not we grant you a reward, you hereby assign to Salesforce all right, title and interest (including all intellectual property rights), in the contents of all vulnerability reports that you submit to Salesforce. \n\nBy participating in the Bug Bounty Program, you represent that you have the right to assign all such right, title and interest to us and that your participation in the Bug Bounty Program and assignment of such right, title and interest will not breach any agreement you may have with a third party (e.g. your employer).\n\n\n_Other Terms and Conditions_\n\n\nSalesforce pledges not to pursue a civil action or initiate a complaint to law enforcement against researchers for security research and vulnerability disclosure activities conducted in accordance with this Policy. We consider security research and vulnerability disclosure activities conducted in accordance with this Policy “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA and applicable anti-hacking laws such as Cal. Penal Code 502(c). We waive any DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy.\n\nBy participating in the Bug Bounty Program, you agree to be bound by these rules. These policies will apply to you in addition to, and will not replace, any other terms and conditions that are imposed by HackerOne.\n\n- Your participation in the Bug Bounty Program does not create any kind of employment relationship or partnership between you and Salesforce. You must not hold yourself out as a Salesforce employee or as someone in any way affiliated with Salesforce.\n- You must comply with all applicable laws in connection with your participation in this program. \n- You are responsible for any applicable taxes associated with any reward you receive. \n- Vulnerability reports received prior to the Bug Bounty Program launch are not eligible for rewards and may not be re-submitted for a reward.\n- You will not use any of our trademarks, service marks and logos.\n- We may modify this Policy at any time by posting an updated version of this document.\n- We may terminate this Bug Bounty Program at any time without notice. \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":[],"timestamp":"2022-12-07T16:54:41.801Z"},{"id":3680486,"new_policy":"## Slack Technologies, LLC, a Salesforce company\n\nOver _$12M_ in bounties awarded across all our H1 Bug Bounty programs since 2015!\n\n\nAt Slack, a Salesforce company, Trust is our #1 value and we take the protection of our customers' data very seriously. As a result, we encourage responsible reporting and disclosure of any vulnerabilities that may be found on our websites, APIs, or applications. \n\nSlack is committed to working with security researchers to verify and address any potential vulnerabilities that are reported to us. If you want to help us make our products safer with the possibility of a reward in the process, you are in the right place!\n\nPlease review these terms before you test and/or report a vulnerability. Slack pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.\n\nEligibility for the Bug Bounty Program \n\n\nUnder our Bug Bounty Program, qualified individuals are encouraged to submit bug reports that detail existing vulnerabilities in certain in-scope Salesforce products and services. In certain circumstances, Salesforce may grant monetary rewards to those who submit vulnerability reports.\n\nWe are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Slack. However, only those researchers that meet the following criteria may be eligible to receive a reward. Some of the requirements to participate in the Bug Bounty Program include:\n\n\n* You must be the first reporter of a vulnerability associated with a participating service (we will also not reward for a known vulnerability which we are actively fixing)\n* You must have personally discovered the vulnerability and you may not report a vulnerability that was discovered by another person (including, and especially, someone who does not qualify to participate in the Bug Bounty Program)\n* You must not be employed by Slack, Salesforce, its subsidiaries, or any related entities, currently or in the last 12 months.\n* You must comply with this Policy when discovering the vulnerability and submitting the vulnerability report\n* Slack or H1 can’t be legally prohibited from rewarding you for any reason\n* Non-automated testing is allowed on production Slack infrastructure, preferably using dedicated test teams. Any testing for cross-team vulnerabilities should be conducted using dedicated teams created and owned by the researcher.\n\nConduct Guidelines\n\n\nWhile we encourage you to discover and report to us any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited and will result in disqualification from the Bug Bounty Program:\n\n\n* Disclosing any vulnerabilities or suspected vulnerabilities you discover to any other person without explicit Salesforce authorization\n* Disclosing the contents of any submission to our program without explicit Slack authorization\n* Accessing private information of any person stored on a Slack product or service – You must use test accounts\n* Accessing sensitive information (e.g., credentials)\n* Performing actions that may negatively affect Salesforce system performance or its users (e.g. Spam, Phishing, Brute force, Distributed Denial of Service (DDoS))\n* Conducting any kind of physical attack on Slack personnel, property or data centers\n* Social engineering any Slack employee or contractor\n* Conduct vulnerability testing of participating services using anything other than test accounts (e.g. Developer or Trial Edition instances)\n* Exfiltrating data. Please test only the minimum necessary to validate a vulnerability (we can verify if data exfiltration would be possible from a vulnerability, and will reward with the impact in mind)\n* Violating any laws or breaching any agreements in order to discover vulnerabilities\n\nIf you are testing a publicly viewable area of Slack (eg. https://success.salesforce.com), please remove any test posts or accounts when you are done and refrain from engaging with actual users.\n\n\nOur Commitment to Researchers\n\n\nIf you submit a vulnerability report, the Salesforce security team and associated development organizations will use reasonable efforts to:\n\n\n\n* Respond in a timely manner, acknowledging receipt of your vulnerability report.\n* Investigate and consider your vulnerability report for eligibility under our Bug Bounty Program within 30 days of submission or less.\n* Notify you when the remediation or other action regarding the vulnerability has been implemented. \n\nSlack Products/Services In Scope for H1 Security Researchers\n\nThe Bug Bounty Program is limited to Slack products as specified within the *scope* section in HackerOne.\n\n\n\nQualifying Vulnerabilities \u0026 Bounties (In Scope)\n\n\nThe decision to grant a reward for a vulnerability report, and the value of a reward (if any), is entirely within Salesforce’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the *impact and severity* of the reported vulnerability. \n\n\n* You will qualify for consideration for a reward only if you are the first person to responsibly disclose an unknown vulnerability to us in accordance with these policies. The determination of whether you are the first person is solely within our responsibility. Vulnerabilities must also be relevant, exploitable, and well-documented in the vulnerability report. We are more likely to grant a reward if the vulnerability is specific, fixable and not currently exploited against us or our customers. \n\nOur target reward range for different types of vulnerabilities within the published scope. Additional bounty may be awarded on top of these base amounts, as determined by the Bug Bounty Management team.\n\n\n*Vulnerability Severity Definitions*\n\nThe following vulnerability severity definitions are based on internal Salesforce documentation. These definitional are a work in progress. The goal of adding these definitions to our policy is to: \n\n* Allow more efficient report triage\n* Align directly with internal Salesforce vulnerability ranking definitions\n* Remove ambiguity and subjective assignment of severity\n* Promote fair bounty payments\n* Promote researcher satisfaction\n\nIf you have feedback and/or suggestions to help us make these more clear and useful, please email your ideas to bugbountymanager@salesforce.com\n\n*Critical*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that can compromise the confidentiality, integrity, or availability of production and corporate resources and/or data with limited exploitation difficulty and/or attacker skill.\n    * Vulnerabilities that could be easily exploited by a remote or unauthenticated attacker and lead to system compromise and/or exposure of highly sensitive or customer data of any kind without requiring user interaction. \n    * Exploitation of a vulnerability that results in a root-level compromise of servers or infrastructure devices.\n* Examples include, but are not limited to:\n    * External facing remote arbitrary code execution without mitigating circumstances. \n    * External facing SQL injection. \n    * External facing unintended single tenant or cross tenant information disclosure and/or multi-tenancy break\n    * Authentication flaws resulting in arbitrary account compromise.\n    * Session management flaws leading to arbitrary account compromise. \n    * External facing credential leaks and default credential usage resulting in access to production systems containing customer data.\n    * Client and server software and system s susceptible to publicly disclosed and exploited vulnerability.\n    * Susceptibility to an external, simply executed, single actor, logic-based attacks resulting in a service outage of one or more critical systems/products.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Critical (In a small subset of cases)\n    * CVSSv3 Temporal Score: 9-10\n    * Qualys Severity 5\n    * nCircle: 1000+ (Based on risk )\n    * PCI Violating Vulnerability: Yes\n    * AppDetective: High (Based on risk )\n    * Whitehat: Urgent\n\n*High*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that can compromise the confidentiality, integrity, or availability of production and corporate resources and data.\n    * Vulnerabilities that could be easily exploited by an internal and/or external, authenticated/unauthenticated attacker and lead to system compromise and/or exposure of highly sensitive or customer data without requiring user interaction.\n    * Vulnerabilities that allow local users to gain increased privileges.\n    * Vulnerabilities that allow unauthenticated remote users to view sensitive information.\n    * Susceptibility to an external, simply executed, single actor, logic-based attacks resulting in significant performance degradation of one or more critical systems/products.\n* Examples include, but are not limited to:\n    * Privilege Escalation  \n    * External facing Persistent/Stored Cross-Site Scripting (XSS).\n    * External facing Cross-Site Request Forgery (CSRF) exposure on sensitive or critical functions.\n    * External facing stack traces containing sensitive information exposed to clients.\n    * Internal network/system use of weak cryptography that is practically exploitable in a real kill chain without nation-state resources.\n    * Internal network/system remote arbitrary code execution without mitigating circumstances.\n    * Internal network/system command or SQL injection without mitigating circumstances.\n    * Internal network/system exposure of sensitive information.\n    * Internal network/system use of default or weak credentials.\n    * Client/Server software and/or systems susceptible to publicly disclosed vulnerability.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Critical/Severe\n    * CVSSv3 Temporal Score: 7 - 8.93\n    * Qualys: Severity 44\n    * nCircle:1000 +\n    * PCI Violating Vuln: Yes\n    * AppDetective: High\n    * Whitehat: Critical\n\n*Medium*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. \n    * Vulnerabilities that could have had a critical or high impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.\n    * Susceptibility to external, simply executed, single actor, logic-based attacks resulting in some measurable performance degradation of one or more critical systems/products.\n* Examples include, but are not limited to:\n    * External unintended internal information disclosure.\n    * Internal network/application Cross-Site Scripting (XSS).\n    * Internal network/application Cross-Site Request Forgery (CSRF).\n    * Internal use of weak cryptography that is practically exploitable in a real kill chain with nation-state resources.\n    * Usage of EoL operating systems or software.\n    * External facing content spoofing.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Moderate\n    * CVSSv3 Temporal Score: 4 - 6.93\n    * Qualys: Severity 34. \n    * nCircle: 500 - 999.5. \n    * PCI Violating Vuln: No\n    * AppDetective: Medium\n    * Whitehat: High\n\n*Low*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that may be more difficult to exploit but could lead to minimal compromise of the confidentiality, integrity, or availability of resources under unlikely circumstances.\n    * These types of vulnerabilities require unlikely circumstances to be able to be exploited, or where a successful exploit would have minimal consequences.\n    * Susceptibility to external, simply executed, single actor, logic-based attacks resulting in minor performance degradation of one or more critical systems/products. \n* Examples include, but are not limited to:\n    * XSS from an authenticated customer admin\n    * Internal default pages or content without vulnerabilities such as an Apache server-status page enabled, allowing anyone browsing it to see the information of the server, as well as any request currently being made.\n    * Exposure of server config information\n    * Use of weak cryptography that is not practically exploitable in a real kill-chain.\n    * External Cross-Site Request Forgery (CSRF) exposure on non-sensitive or non-critical functions.\n    * Documentation bugs\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Moderate (Informational in nature)\n    * CVSSv3 Temporal Score: 0.1 -3.93\n    * Qualys: Severity 24\n    * nCircle: 1 -499.5.\n    * PCI Violating Vuln: No\n    * AppDetective: Low 7\n    * Whitehat: Low\n\n*Qualifying Vulnerability Descriptions*\n\n\n| Category | Description |\n| --- | --- |\n| Remote Code Execution | CWE-94: AKA \"Arbitrary Code Execution\".  Describes a security bug that allows an attacker to execute arbitrary commands or code on a target machine or in a target process. The exploit PoC may include many other vulnerability types, but ultimately the result is p0wnage of the server(s) and/or environment.  [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Disclosure of Credit Card data | CWE-359:  This is self-explanatory. Any security bug which allows disclosure of credit card information to an unauthorized user or system qualifies as Disclosure of Credit Card Data |\n| SQL Injection | CWE-1027:  SQL injection is a code injection technique in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Unrestricted XXE / File System Access | CWE-611:  External XML Entity Injection (XXE) is a specific type of Server Side Request Forgery(SSRF) which affects an XML processing engine server-side on a target. Specifically, blind XXE is when the results are either error-based or cause 3rd party interaction with services such as HTTP, FTP \u0026 DNS. An XXE attack typically occurs when XML input containing a reference to an external entity is processed by a weakly configured parser. An attacker can leverage an XXE attack to access sensitive data and read local or remote files. In a similar manner to SSRF, an attacker could introduce malicious code through Remote Code Execution (RCE).  [scr: https://blog.zsec.uk/out-of-band-xxe-2/]  [src: https://chris-young.net/2018/04/13/xxe-xml-external-entity/] |\n| Significant Authentication Bypass | CWE-305:  Authentication bypass is a vulnerability that allows an attacker access to credential protected resources without first acquiring valid credentials. Examples of this vulnerability include:* SQL injection during login to bypasses credential authentication* Direct access to resources normally beyond an authentication mechanism, such as a login screen, which do not independently validate the users authenticated session.* Failure to enumerate and enforce the systems' access policy. * A weak authentication system that allows a valid identity to be forged. | \n| Significant Authorization Bypass | CWE-285:  Authorization is the concept of allowing access to resources only to those permitted to use them. Vulnerabilities that bypass authorization checks may allow access to protected resources beyond what was intended by the system. Examples of authorization bypass include Insecure Direct Object Reference and Session Token Alteration. In each of these examples, the system trusts the users' requests because of improper or insecure implementation. |\n| Cross Instance Privilege Escalation | Salesforce is a multi-tenant platform in which \"instances\" are created for each Org. A cross-instance privilege escalation involves some user in instance A having access to data in instance B without proper authorization. |\n| Denial of Service | Susceptibility to an external, simply executed, single actor, logic-based attack resulting in a service outage or significant performance degradation of one or more critical systems/products  |\n| Disclosure of Personal Identifiable Information | CWE-200:  Personally identifiable information, or PII, is any data that could potentially be used to identify a particular person. As it relates to Salesforce, PII Disclosure bugs involve PII data stored within any in-scope platforms, excluding Salesforce Employee data such as Name and Contact information.  [src: https://www.lifelock.com/learn-identity-theft-resources-what-is-personally-identifiable-information.html] |\n| Salesforce Platform Misconfiguration and/or Custom APEX Vulnerabilities (Salesforce Owned/Controlled) | The Salesforce Platform is highly configurable, customizable, and supports custom code in the form of APEX code, Visualforce pages, etc. It is therefore capable of being misconfigured in such a way as to leak information or to otherwise be insecure. This category of vulnerability is specific to Salesforce owned and operated sites, NOT Salesforce customer-owned and operated Salesforce instances. If you identify a configuration vulnerability in a customer site please report it to that company via their Bug Bounty program or their security@\u003csome company dot com\u003e email address. There is no guarantee that the customer will respond to your email or bug submission, and it is out of Salesforce control. Please do not expect Salesforce to handle reports of customer misconfiguration.|\n| Privilege Escalation / Improper Access Control | Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in a software application to gain elevated access to resources that are normally protected from an application or user. The result is that a user with more privileges than intended by the application developer or system administrator can perform unauthorized actions. Note that Privilege Escalation is different from Permission Model Circumvention in that PE involves accessing functionality beyond that assigned to a given role, or somehow adding resource permissions to a given role without authorization, while PMC involves a complete bypass of security controls meant to enforce permissions. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access.  [src: https://en.wikipedia.org/wiki/Privilege_escalation] |\n| Non-XXE SSRF | In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.[src:https://www.owasp.org/index.php/Server_Side_Request_Forgery] |\n| Insecure Direct Object Reference | IDOR occurs when unvalidated user-supplied input is submitted and direct access to the object requested is provided. Vulnerability reports for IDOR are valid when the result is unauthorized information disclosure, modification or destruction of data, or performing a function outside of the limits of the current user. |\n| CRLF injection/HTTP response splitting  | HTTP response splitting occurs when data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. [src: https://www.owasp.org/index.php/HTTP_Response_Splitting] |\n| Circumvention of our Platform’s Permission Model | Permission Model Circumvention involves a complete bypass of security controls meant to enforce permissions. An example of PMC involves an insecurely configured system in which an API gateway fronts for several servers and implements authentication/authorization. The configuration is such that the URI to the backend servers can be identified and they are directly accessible without any additional authentication or authorization checks..While there is an authX model in place, it was trivially circumventable. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access. |\n| Cross-Site Scripting (excluding self-XSS) | CWE-80:  Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. [src:https://en.wikipedia.org/wiki/Cross-site_scripting] |\n| Cross-Site Request Forgery (CSRF) on critical actions | CWE-352:  Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.  [src: https://en.wikipedia.org/wiki/Cross-site_request_forgery] |\n| Insufficiently Protected Credentials / Credential Exposure | CWE-522:  CWE-522: Within the context of the Salesforce/HackerOne Bug Bounty program, credential exposure involves finding, or gaining access to a user or system credentials which are not meant to be public. An example of IPC would be finding a Github or other repo containing configuration files that contain usernames, passwords, API keys, private keys, etc. Another example is an exposure of a single user's credentials on the querystring, in cookies, or in other HTTP headers. |\n| Insecure/Open Redirect | CWE-601:  An HTTP parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. |\n| DNS Hijacking / Subdomain Takeover | DNS hijacking or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries.The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.  [src: https://en.wikipedia.org/wiki/DNS_hijacking] [src: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers] |\n| Configuration/Stats//Log File Exposure | CWE-532 Information Exposure Through Log Files. CWE-200: Information Exposure. Any instance in which log files or server/application configuration files are accessible when they are not meant to be. |\n| Documentation Bug | Any instance in which, from a strictly security-based perspective, the published documentation is incorrect with regard to the behavior of the product. | \n\n\nNon-Qualifying Vulnerabilities (Out of Scope)\n\n\nThe following types of issues are *specifically excluded* from our Bug Bounty Program:\n* CSRF-able actions that do not require authentication (or a session) to exploit or CSRF issues which have no security impact to Slack.\n\n*Commerce Cloud Specific*\n\n* XSS that is stored in Business Manager and is reflected in the storefront / executed in a Storefront context.\n* Admin to Admin or Admin to User XSS. In these cases, a higher privileged user is attempting to attack the lower privileged user. As an admin, such script execution is considered a feature due to the nature of the platform.\n* CSRF in Storefront\n* CSRF that can only be used to make modifications on the file system\n* Session Fixation inside of Storefront\n* XSS in the following areas: HTML Editor and file upload\n* Login Page / Forgot Password Page Account Brute force or account lockout not enforced\n* Submissions regarding product deficiencies, as opposed to exploitable vulnerabilities\n\n*Other Clouds and Services (Including Commerce Cloud)*\n\n* Access control to objects and fields in Salesforce are done through permission set or profile in setup tree. If that permission or profile in the setup tree is not respected, only then it is considered as an access control issue. Please check all permissions \u0026 profiles for that particular user before filling access control bugs.\n* HTML and Link injections\n* Issues related to \"Editable Github Wiki Pages\"\n* Issues related to Salesforce *Partner* User Credential Disclosure in public code repositories such as GitHub. *Please note that this type of activity is explicitly excluded by the Conduct Guidelines in this policy.*\n* TOCTOU bugs involving platform permission changes. For example; User A has an active session, Admin reduces or increases permissions for User A, User A permissions do not change until User A logs out and back in. This is currently WAD on Salesforce platforms.\n* Invalid links from any Salesforce site to any social media site in which a claim of \"account takeover\" or \"possible phishing attacks\" are the basis for the report.\n* Bugs in content/services that are not owned/operated by Salesforce\n* Vulnerabilities affecting users of outdated or unsupported browsers or platforms\n* Vulnerabilities that have already been addressed in a product update regardless of whether the update has been applied to the publicly available research machines\n* Subdomain takeovers for out of scope domains\n* Self-XSS or XSS bugs requiring an unlikely amount of user interaction\n* XSS in our content sandbox under .content.force.com (http://content.force.com/)\n\n- XSS under \\.sitepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.livepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.visual.force.com (with the exception of Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n\n* XSS in custom apps under .force.com (with the exception of lightning.force.com and Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n\n- Bugs categorized as P3 (low risk)\n- SalesforceDX: Attacks by a root user against another user on the same machine\n- SalesforceDX: Attacks by a user on the same user\n- CSRF on forms that are available to anonymous users (e.g. web2lead contact form)\n- Clickjacking and issues only exploitable through clickjacking\n- Descriptive error messages (e.g. Stack Traces, application or server errors)\n- HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n- Fingerprinting / banner disclosure on common/public services.\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Scripting or other automation and brute-forcing of intended functionality\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n- Lack of Secure and HTTPOnly cookie flags\n- Content spoofing (text injection) or IDN homograph attacks\n- Tabnabbing \n- Email configuration issues (SPF, DKIM, DMARC)\n- Weak Captcha / Captcha Bypass\n- Forced Login / Logout CSRF\n- Account lockout, Login or Forgot Password page brute force\n- Password complexity or account recovery policies\n- Username / email enumeration (brute force)\n- HTTPS Mixed Content\n- Missing HTTP security headers, specifically: Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy.\n- OPTIONS HTTP method enabled\n- Known SSL issues (e.g. attacks such as BEAST, BREACH, POODLE, TLS Renegotiation)\n- SSL Forward Secrecy or HSTS not enabled\n- Weak SSL/TLS Cipher Suites\n- CSV Excel Formula injection\n- Issues related to networking protocols or industry standards not controlled by Salesforce\n- Sending vulnerability reports using automated tools without validation\n- Use of a known-vulnerable library without evidence of exploitability\n- Problems related to widely publicized CVE's\n- Attacks requiring physical access to a user's unlocked device\n- Reports of spam, phishing or security best practices\n- Reflected XSS involving Adobe Flash files (.swf)\n\n*If you are unsure whether a bug or issue that you discover in a participating service is a non-qualifying vulnerability, please email us at \u003cbugbountymanager@salesforce.com\u003e*\n\n\n_Intellectual Property_\n\n\nParticipating in the Bug Bounty Program does not grant to you or any other third party any rights to any Slack or Salesforce intellectual property, product or service. All rights not otherwise granted herein are expressly reserved. Whether or not we grant you a reward, you hereby assign to Salesforce all right, title and interest (including all intellectual property rights), in the contents of all vulnerability reports that you submit to Salesforce. \n\nBy participating in the Bug Bounty Program, you represent that you have the right to assign all such right, title and interest to us and that your participation in the Bug Bounty Program and assignment of such right, title and interest will not breach any agreement you may have with a third party (e.g. your employer).\n\n\n_Other Terms and Conditions_\n\n\nSalesforce pledges not to pursue a civil action or initiate a complaint to law enforcement against researchers for security research and vulnerability disclosure activities conducted in accordance with this Policy. We consider security research and vulnerability disclosure activities conducted in accordance with this Policy “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA and applicable anti-hacking laws such as Cal. Penal Code 502(c). We waive any DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy.\n\nBy participating in the Bug Bounty Program, you agree to be bound by these rules. These policies will apply to you in addition to, and will not replace, any other terms and conditions that are imposed by HackerOne.\n\n- Your participation in the Bug Bounty Program does not create any kind of employment relationship or partnership between you and Salesforce. You must not hold yourself out as a Salesforce employee or as someone in any way affiliated with Salesforce.\n- You must comply with all applicable laws in connection with your participation in this program. \n- You are responsible for any applicable taxes associated with any reward you receive. \n- Vulnerability reports received prior to the Bug Bounty Program launch are not eligible for rewards and may not be re-submitted for a reward.\n- You will not use any of our trademarks, service marks and logos.\n- We may modify this Policy at any time by posting an updated version of this document.\n- We may terminate this Bug Bounty Program at any time without notice. \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":[],"timestamp":"2022-11-30T16:39:29.486Z"},{"id":3668577,"new_policy":"## Slack Technologies, LLC, a Salesforce company\n\nOver _$12M_ in bounties awarded across all our H1 Bug Bounty programs since 2015!\n\n\nAt Slack, a Salesforce company, Trust is our #1 value and we take the protection of our customers' data very seriously. As a result, we encourage responsible reporting and disclosure of any vulnerabilities that may be found on our websites, APIs, or applications. \n\nSlack is committed to working with security researchers to verify and address any potential vulnerabilities that are reported to us. If you want to help us make our products safer with the possibility of a reward in the process, you are in the right place!\n\nPlease review these terms before you test and/or report a vulnerability. Slack pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.\n\nEligibility for the Bug Bounty Program \n\n\nUnder our Bug Bounty Program, qualified individuals are encouraged to submit bug reports that detail existing vulnerabilities in certain in-scope Salesforce products and services. In certain circumstances, Salesforce may grant monetary rewards to those who submit vulnerability reports.\n\nWe are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Slack. However, only those researchers that meet the following criteria may be eligible to receive a reward. Some of the requirements to participate in the Bug Bounty Program include:\n\n\n* You must be the first reporter of a vulnerability associated with a participating service (we will also not reward for a known vulnerability which we are actively fixing)\n* You must have personally discovered the vulnerability and you may not report a vulnerability that was discovered by another person (including, and especially, someone who does not qualify to participate in the Bug Bounty Program)\n* You must not be employed by Slack, Salesforce, its subsidiaries, or any related entities, currently or in the last 12 months.\n* You must comply with this Policy when discovering the vulnerability and submitting the vulnerability report\n* Slack or H1 can’t be legally prohibited from rewarding you for any reason\n* Non-automated testing is allowed on production Slack infrastructure, preferably using dedicated test teams. Any testing for cross-team vulnerabilities should be conducted using dedicated teams created and owned by the researcher.\n\nConduct Guidelines\n\n\nWhile we encourage you to discover and report to us any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited and will result in disqualification from the Bug Bounty Program:\n\n\n* Disclosing any vulnerabilities or suspected vulnerabilities you discover to any other person without explicit Salesforce authorization\n* Disclosing the contents of any submission to our program without explicit Slack authorization\n* Accessing private information of any person stored on a Slack product or service – You must use test accounts\n* Accessing sensitive information (e.g., credentials)\n* Performing actions that may negatively affect Salesforce system performance or its users (e.g. Spam, Phishing, Brute force, Distributed Denial of Service (DDoS))\n* Conducting any kind of physical attack on Slack personnel, property or data centers\n* Social engineering any Slack employee or contractor\n* Conduct vulnerability testing of participating services using anything other than test accounts (e.g. Developer or Trial Edition instances)\n* Exfiltrating data. Please test only the minimum necessary to validate a vulnerability (we can verify if data exfiltration would be possible from a vulnerability, and will reward with the impact in mind)\n* Violating any laws or breaching any agreements in order to discover vulnerabilities\n\nIf you are testing a publicly viewable area of Slack (eg. https://success.salesforce.com), please remove any test posts or accounts when you are done and refrain from engaging with actual users.\n\n\nOur Commitment to Researchers\n\n\nIf you submit a vulnerability report, the Salesforce security team and associated development organizations will use reasonable efforts to:\n\n\n\n* Respond in a timely manner, acknowledging receipt of your vulnerability report.\n* Investigate and consider your vulnerability report for eligibility under our Bug Bounty Program within 30 days of submission or less.\n* Notify you when the remediation or other action regarding the vulnerability has been implemented. \n\nSlack Products/Services In Scope for H1 Security Researchers\n\nThe Bug Bounty Program is limited to Slack products as specified within the *scope* section in HackerOne.\n\n\n\nQualifying Vulnerabilities \u0026 Bounties (In Scope)\n\n\nThe decision to grant a reward for a vulnerability report, and the value of a reward (if any), is entirely within Salesforce’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the *impact and severity* of the reported vulnerability. \n\n\n* You will qualify for consideration for a reward only if you are the first person to responsibly disclose an unknown vulnerability to us in accordance with these policies. The determination of whether you are the first person is solely within our responsibility. Vulnerabilities must also be relevant, exploitable, and well-documented in the vulnerability report. We are more likely to grant a reward if the vulnerability is specific, fixable and not currently exploited against us or our customers. \n\nOur target reward range for different types of vulnerabilities within the published scope. Additional bounty may be awarded on top of these base amounts, as determined by the Bug Bounty Management team.\n\n\n*Vulnerability Severity Definitions*\n\nThe following vulnerability severity definitions are based on internal Salesforce documentation. These definitional are a work in progress. The goal of adding these definitions to our policy is to: \n\n* Allow more efficient report triage\n* Align directly with internal Salesforce vulnerability ranking definitions\n* Remove ambiguity and subjective assignment of severity\n* Promote fair bounty payments\n* Promote researcher satisfaction\n\nIf you have feedback and/or suggestions to help us make these more clear and useful, please email your ideas to bugbountymanager@salesforce.com\n\n*Critical*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that can compromise the confidentiality, integrity, or availability of production and corporate resources and/or data with limited exploitation difficulty and/or attacker skill.\n    * Vulnerabilities that could be easily exploited by a remote or unauthenticated attacker and lead to system compromise and/or exposure of highly sensitive or customer data of any kind without requiring user interaction. \n    * Exploitation of a vulnerability that results in a root-level compromise of servers or infrastructure devices.\n* Examples include, but are not limited to:\n    * External facing remote arbitrary code execution without mitigating circumstances. \n    * External facing SQL injection. \n    * External facing unintended single tenant or cross tenant information disclosure and/or multi-tenancy break\n    * Authentication flaws resulting in arbitrary account compromise.\n    * Session management flaws leading to arbitrary account compromise. \n    * External facing credential leaks and default credential usage resulting in access to production systems containing customer data.\n    * Client and server software and system s susceptible to publicly disclosed and exploited vulnerability.\n    * Susceptibility to an external, simply executed, single actor, logic-based attacks resulting in a service outage of one or more critical systems/products.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Critical (In a small subset of cases)\n    * CVSSv3 Temporal Score: 9-10\n    * Qualys Severity 5\n    * nCircle: 1000+ (Based on risk )\n    * PCI Violating Vulnerability: Yes\n    * AppDetective: High (Based on risk )\n    * Whitehat: Urgent\n\n*High*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that can compromise the confidentiality, integrity, or availability of production and corporate resources and data.\n    * Vulnerabilities that could be easily exploited by an internal and/or external, authenticated/unauthenticated attacker and lead to system compromise and/or exposure of highly sensitive or customer data without requiring user interaction.\n    * Vulnerabilities that allow local users to gain increased privileges.\n    * Vulnerabilities that allow unauthenticated remote users to view sensitive information.\n    * Susceptibility to an external, simply executed, single actor, logic-based attacks resulting in significant performance degradation of one or more critical systems/products.\n* Examples include, but are not limited to:\n    * Privilege Escalation  \n    * External facing Persistent/Stored Cross-Site Scripting (XSS).\n    * External facing Cross-Site Request Forgery (CSRF) exposure on sensitive or critical functions.\n    * External facing stack traces containing sensitive information exposed to clients.\n    * Internal network/system use of weak cryptography that is practically exploitable in a real kill chain without nation-state resources.\n    * Internal network/system remote arbitrary code execution without mitigating circumstances.\n    * Internal network/system command or SQL injection without mitigating circumstances.\n    * Internal network/system exposure of sensitive information.\n    * Internal network/system use of default or weak credentials.\n    * Client/Server software and/or systems susceptible to publicly disclosed vulnerability.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Critical/Severe\n    * CVSSv3 Temporal Score: 7 - 8.93\n    * Qualys: Severity 44\n    * nCircle:1000 +\n    * PCI Violating Vuln: Yes\n    * AppDetective: High\n    * Whitehat: Critical\n\n*Medium*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. \n    * Vulnerabilities that could have had a critical or high impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.\n    * Susceptibility to external, simply executed, single actor, logic-based attacks resulting in some measurable performance degradation of one or more critical systems/products.\n* Examples include, but are not limited to:\n    * External unintended internal information disclosure.\n    * Internal network/application Cross-Site Scripting (XSS).\n    * Internal network/application Cross-Site Request Forgery (CSRF).\n    * Internal use of weak cryptography that is practically exploitable in a real kill chain with nation-state resources.\n    * Usage of EoL operating systems or software.\n    * External facing content spoofing.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Moderate\n    * CVSSv3 Temporal Score: 4 - 6.93\n    * Qualys: Severity 34. \n    * nCircle: 500 - 999.5. \n    * PCI Violating Vuln: No\n    * AppDetective: Medium\n    * Whitehat: High\n\n*Low*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that may be more difficult to exploit but could lead to minimal compromise of the confidentiality, integrity, or availability of resources under unlikely circumstances.\n    * These types of vulnerabilities require unlikely circumstances to be able to be exploited, or where a successful exploit would have minimal consequences.\n    * Susceptibility to external, simply executed, single actor, logic-based attacks resulting in minor performance degradation of one or more critical systems/products. \n* Examples include, but are not limited to:\n    * XSS from an authenticated customer admin\n    * Internal default pages or content without vulnerabilities such as an Apache server-status page enabled, allowing anyone browsing it to see the information of the server, as well as any request currently being made.\n    * Exposure of server config information\n    * Use of weak cryptography that is not practically exploitable in a real kill-chain.\n    * External Cross-Site Request Forgery (CSRF) exposure on non-sensitive or non-critical functions.\n    * Documentation bugs\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Moderate (Informational in nature)\n    * CVSSv3 Temporal Score: 0.1 -3.93\n    * Qualys: Severity 24\n    * nCircle: 1 -499.5.\n    * PCI Violating Vuln: No\n    * AppDetective: Low 7\n    * Whitehat: Low\n\n*Qualifying Vulnerability Descriptions*\n\n\n| Category | Description |\n| --- | --- |\n| Remote Code Execution | CWE-94: AKA \"Arbitrary Code Execution\".  Describes a security bug that allows an attacker to execute arbitrary commands or code on a target machine or in a target process. The exploit PoC may include many other vulnerability types, but ultimately the result is p0wnage of the server(s) and/or environment.  [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Disclosure of Credit Card data | CWE-359:  This is self-explanatory. Any security bug which allows disclosure of credit card information to an unauthorized user or system qualifies as Disclosure of Credit Card Data |\n| SQL Injection | CWE-1027:  SQL injection is a code injection technique in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Unrestricted XXE / File System Access | CWE-611:  External XML Entity Injection (XXE) is a specific type of Server Side Request Forgery(SSRF) which affects an XML processing engine server-side on a target. Specifically, blind XXE is when the results are either error-based or cause 3rd party interaction with services such as HTTP, FTP \u0026 DNS. An XXE attack typically occurs when XML input containing a reference to an external entity is processed by a weakly configured parser. An attacker can leverage an XXE attack to access sensitive data and read local or remote files. In a similar manner to SSRF, an attacker could introduce malicious code through Remote Code Execution (RCE).  [scr: https://blog.zsec.uk/out-of-band-xxe-2/]  [src: https://chris-young.net/2018/04/13/xxe-xml-external-entity/] |\n| Significant Authentication Bypass | CWE-305:  Authentication bypass is a vulnerability that allows an attacker access to credential protected resources without first acquiring valid credentials. Examples of this vulnerability include:* SQL injection during login to bypasses credential authentication* Direct access to resources normally beyond an authentication mechanism, such as a login screen, which do not independently validate the users authenticated session.* Failure to enumerate and enforce the systems' access policy. * A weak authentication system that allows a valid identity to be forged. | \n| Significant Authorization Bypass | CWE-285:  Authorization is the concept of allowing access to resources only to those permitted to use them. Vulnerabilities that bypass authorization checks may allow access to protected resources beyond what was intended by the system. Examples of authorization bypass include Insecure Direct Object Reference and Session Token Alteration. In each of these examples, the system trusts the users' requests because of improper or insecure implementation. |\n| Cross Instance Privilege Escalation | Salesforce is a multi-tenant platform in which \"instances\" are created for each Org. A cross-instance privilege escalation involves some user in instance A having access to data in instance B without proper authorization. |\n| Denial of Service | Susceptibility to an external, simply executed, single actor, logic-based attack resulting in a service outage or significant performance degradation of one or more critical systems/products  |\n| Disclosure of Personal Identifiable Information | CWE-200:  Personally identifiable information, or PII, is any data that could potentially be used to identify a particular person. As it relates to Salesforce, PII Disclosure bugs involve PII data stored within any in-scope platforms, excluding Salesforce Employee data such as Name and Contact information.  [src: https://www.lifelock.com/learn-identity-theft-resources-what-is-personally-identifiable-information.html] |\n| Salesforce Platform Misconfiguration and/or Custom APEX Vulnerabilities (Salesforce Owned/Controlled) | The Salesforce Platform is highly configurable, customizable, and supports custom code in the form of APEX code, Visualforce pages, etc. It is therefore capable of being misconfigured in such a way as to leak information or to otherwise be insecure. This category of vulnerability is specific to Salesforce owned and operated sites, NOT Salesforce customer-owned and operated Salesforce instances. If you identify a configuration vulnerability in a customer site please report it to that company via their Bug Bounty program or their security@\u003csome company dot com\u003e email address. There is no guarantee that the customer will respond to your email or bug submission, and it is out of Salesforce control. Please do not expect Salesforce to handle reports of customer misconfiguration.|\n| Privilege Escalation / Improper Access Control | Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in a software application to gain elevated access to resources that are normally protected from an application or user. The result is that a user with more privileges than intended by the application developer or system administrator can perform unauthorized actions. Note that Privilege Escalation is different from Permission Model Circumvention in that PE involves accessing functionality beyond that assigned to a given role, or somehow adding resource permissions to a given role without authorization, while PMC involves a complete bypass of security controls meant to enforce permissions. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access.  [src: https://en.wikipedia.org/wiki/Privilege_escalation] |\n| Non-XXE SSRF | In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.[src:https://www.owasp.org/index.php/Server_Side_Request_Forgery] |\n| Insecure Direct Object Reference | IDOR occurs when unvalidated user-supplied input is submitted and direct access to the object requested is provided. Vulnerability reports for IDOR are valid when the result is unauthorized information disclosure, modification or destruction of data, or performing a function outside of the limits of the current user. |\n| CRLF injection/HTTP response splitting  | HTTP response splitting occurs when data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. [src: https://www.owasp.org/index.php/HTTP_Response_Splitting] |\n| Circumvention of our Platform’s Permission Model | Permission Model Circumvention involves a complete bypass of security controls meant to enforce permissions. An example of PMC involves an insecurely configured system in which an API gateway fronts for several servers and implements authentication/authorization. The configuration is such that the URI to the backend servers can be identified and they are directly accessible without any additional authentication or authorization checks..While there is an authX model in place, it was trivially circumventable. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access. |\n| Cross-Site Scripting (excluding self-XSS) | CWE-80:  Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. [src:https://en.wikipedia.org/wiki/Cross-site_scripting] |\n| Cross-Site Request Forgery (CSRF) on critical actions | CWE-352:  Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.  [src: https://en.wikipedia.org/wiki/Cross-site_request_forgery] |\n| Insufficiently Protected Credentials / Credential Exposure | CWE-522:  CWE-522: Within the context of the Salesforce/HackerOne Bug Bounty program, credential exposure involves finding, or gaining access to a user or system credentials which are not meant to be public. An example of IPC would be finding a Github or other repo containing configuration files that contain usernames, passwords, API keys, private keys, etc. Another example is an exposure of a single user's credentials on the querystring, in cookies, or in other HTTP headers. |\n| Insecure/Open Redirect | CWE-601:  An HTTP parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. |\n| DNS Hijacking / Subdomain Takeover | DNS hijacking or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries.The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.  [src: https://en.wikipedia.org/wiki/DNS_hijacking] [src: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers] |\n| Configuration/Stats//Log File Exposure | CWE-532 Information Exposure Through Log Files. CWE-200: Information Exposure. Any instance in which log files or server/application configuration files are accessible when they are not meant to be. |\n| Documentation Bug | Any instance in which, from a strictly security-based perspective, the published documentation is incorrect with regard to the behavior of the product. | \n\n\nNon-Qualifying Vulnerabilities (Out of Scope)\n\n\nThe following types of issues are *specifically excluded* from our Bug Bounty Program:\n\n*Commerce Cloud Specific*\n\n* XSS that is stored in Business Manager and is reflected in the storefront / executed in a Storefront context.\n* Admin to Admin or Admin to User XSS. In these cases, a higher privileged user is attempting to attack the lower privileged user. As an admin, such script execution is considered a feature due to the nature of the platform.\n* CSRF in Storefront\n* CSRF that can only be used to make modifications on the file system\n* Session Fixation inside of Storefront\n* XSS in the following areas: HTML Editor and file upload\n* Login Page / Forgot Password Page Account Brute force or account lockout not enforced\n* Submissions regarding product deficiencies, as opposed to exploitable vulnerabilities\n\n*Other Clouds and Services (Including Commerce Cloud)*\n\n* Access control to objects and fields in Salesforce are done through permission set or profile in setup tree. If that permission or profile in the setup tree is not respected, only then it is considered as an access control issue. Please check all permissions \u0026 profiles for that particular user before filling access control bugs.\n* HTML and Link injections\n* Issues related to \"Editable Github Wiki Pages\"\n* Issues related to Salesforce *Partner* User Credential Disclosure in public code repositories such as GitHub. *Please note that this type of activity is explicitly excluded by the Conduct Guidelines in this policy.*\n* TOCTOU bugs involving platform permission changes. For example; User A has an active session, Admin reduces or increases permissions for User A, User A permissions do not change until User A logs out and back in. This is currently WAD on Salesforce platforms.\n* Invalid links from any Salesforce site to any social media site in which a claim of \"account takeover\" or \"possible phishing attacks\" are the basis for the report.\n* Bugs in content/services that are not owned/operated by Salesforce\n* Vulnerabilities affecting users of outdated or unsupported browsers or platforms\n* Vulnerabilities that have already been addressed in a product update regardless of whether the update has been applied to the publicly available research machines\n* Subdomain takeovers for out of scope domains\n* Self-XSS or XSS bugs requiring an unlikely amount of user interaction\n* XSS in our content sandbox under .content.force.com (http://content.force.com/)\n\n- XSS under \\.sitepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.livepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.visual.force.com (with the exception of Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n\n* XSS in custom apps under .force.com (with the exception of lightning.force.com and Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n\n- Bugs categorized as P3 (low risk)\n- SalesforceDX: Attacks by a root user against another user on the same machine\n- SalesforceDX: Attacks by a user on the same user\n- CSRF on forms that are available to anonymous users (e.g. web2lead contact form)\n- Clickjacking and issues only exploitable through clickjacking\n- Descriptive error messages (e.g. Stack Traces, application or server errors)\n- HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n- Fingerprinting / banner disclosure on common/public services.\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Scripting or other automation and brute-forcing of intended functionality\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n- Lack of Secure and HTTPOnly cookie flags\n- Content spoofing (text injection) or IDN homograph attacks\n- Tabnabbing \n- Email configuration issues (SPF, DKIM, DMARC)\n- Weak Captcha / Captcha Bypass\n- Forced Login / Logout CSRF\n- Account lockout, Login or Forgot Password page brute force\n- Password complexity or account recovery policies\n- Username / email enumeration (brute force)\n- HTTPS Mixed Content\n- Missing HTTP security headers, specifically: Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy.\n- OPTIONS HTTP method enabled\n- Known SSL issues (e.g. attacks such as BEAST, BREACH, POODLE, TLS Renegotiation)\n- SSL Forward Secrecy or HSTS not enabled\n- Weak SSL/TLS Cipher Suites\n- CSV Excel Formula injection\n- Issues related to networking protocols or industry standards not controlled by Salesforce\n- Sending vulnerability reports using automated tools without validation\n- Use of a known-vulnerable library without evidence of exploitability\n- Problems related to widely publicized CVE's\n- Attacks requiring physical access to a user's unlocked device\n- Reports of spam, phishing or security best practices\n- Reflected XSS involving Adobe Flash files (.swf)\n\n*If you are unsure whether a bug or issue that you discover in a participating service is a non-qualifying vulnerability, please email us at \u003cbugbountymanager@salesforce.com\u003e*\n\n\n_Intellectual Property_\n\n\nParticipating in the Bug Bounty Program does not grant to you or any other third party any rights to any Slack or Salesforce intellectual property, product or service. All rights not otherwise granted herein are expressly reserved. Whether or not we grant you a reward, you hereby assign to Salesforce all right, title and interest (including all intellectual property rights), in the contents of all vulnerability reports that you submit to Salesforce. \n\nBy participating in the Bug Bounty Program, you represent that you have the right to assign all such right, title and interest to us and that your participation in the Bug Bounty Program and assignment of such right, title and interest will not breach any agreement you may have with a third party (e.g. your employer).\n\n\n_Other Terms and Conditions_\n\n\nSalesforce pledges not to pursue a civil action or initiate a complaint to law enforcement against researchers for security research and vulnerability disclosure activities conducted in accordance with this Policy. We consider security research and vulnerability disclosure activities conducted in accordance with this Policy “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA and applicable anti-hacking laws such as Cal. Penal Code 502(c). We waive any DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy.\n\nBy participating in the Bug Bounty Program, you agree to be bound by these rules. These policies will apply to you in addition to, and will not replace, any other terms and conditions that are imposed by HackerOne.\n\n- Your participation in the Bug Bounty Program does not create any kind of employment relationship or partnership between you and Salesforce. You must not hold yourself out as a Salesforce employee or as someone in any way affiliated with Salesforce.\n- You must comply with all applicable laws in connection with your participation in this program. \n- You are responsible for any applicable taxes associated with any reward you receive. \n- Vulnerability reports received prior to the Bug Bounty Program launch are not eligible for rewards and may not be re-submitted for a reward.\n- You will not use any of our trademarks, service marks and logos.\n- We may modify this Policy at any time by posting an updated version of this document.\n- We may terminate this Bug Bounty Program at any time without notice. \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":[],"timestamp":"2022-03-28T22:31:47.704Z"},{"id":3666098,"new_policy":"## Slack Technologies, LLC, a Salesforce company\n\nOver _$12M_ in bounties awarded across all our H1 Bug Bounty programs since 2015!\n\n\nAt Slack, a Salesforce company, Trust is our #1 value and we take the protection of our customers' data very seriously. As a result, we encourage responsible reporting and disclosure of any vulnerabilities that may be found on our websites, APIs, or applications. \n\nSlack is committed to working with security researchers to verify and address any potential vulnerabilities that are reported to us. If you want to help us make our products safer with the possibility of a reward in the process, you are in the right place!\n\nPlease review these terms before you test and/or report a vulnerability. Slack pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.\n\nEligibility for the Bug Bounty Program \n\n\nUnder our Bug Bounty Program, qualified individuals are encouraged to submit bug reports that detail existing vulnerabilities in certain in-scope Salesforce products and services. In certain circumstances, Salesforce may grant monetary rewards to those who submit vulnerability reports.\n\nWe are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Slack. However, only those researchers that meet the following criteria may be eligible to receive a reward. Some of the requirements to participate in the Bug Bounty Program include:\n\n\n* You must be the first reporter of a vulnerability associated with a participating service (we will also not reward for a known vulnerability which we are actively fixing)\n* You must have personally discovered the vulnerability and you may not report a vulnerability that was discovered by another person (including, and especially, someone who does not qualify to participate in the Bug Bounty Program)\n* You must not be employed by Slack, Salesforce, its subsidiaries, or any related entities, currently or in the last 12 months.\n* You must comply with this Policy when discovering the vulnerability and submitting the vulnerability report\n* Slack or H1 can’t be legally prohibited from rewarding you for any reason\n* You must conduct all vulnerability testing against non-production Developer or Trial Edition instances of the participating sites (listed in scope) and services (listed below). Testing against real, production systems, or partner implementations, is strictly prohibited. All Developer or Trial Edition instances of the participating sites typically have the same release of code. Preview instances of in-scope sites and services are also in scope.\n\nConduct Guidelines\n\n\nWhile we encourage you to discover and report to us any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited and will result in disqualification from the Bug Bounty Program:\n\n\n* Disclosing any vulnerabilities or suspected vulnerabilities you discover to any other person without explicit Salesforce authorization\n* Disclosing the contents of any submission to our program without explicit Slack authorization\n* Accessing private information of any person stored on a Slack product or service – You must use test accounts\n* Accessing sensitive information (e.g., credentials)\n* Performing actions that may negatively affect Salesforce system performance or its users (e.g. Spam, Phishing, Brute force, Distributed Denial of Service (DDoS))\n* Conducting any kind of physical attack on Slack personnel, property or data centers\n* Social engineering any Slack employee or contractor\n* Conduct vulnerability testing of participating services using anything other than test accounts (e.g. Developer or Trial Edition instances)\n* Exfiltrating data. Please test only the minimum necessary to validate a vulnerability (we can verify if data exfiltration would be possible from a vulnerability, and will reward with the impact in mind)\n* Violating any laws or breaching any agreements in order to discover vulnerabilities\n\nIf you are testing a publicly viewable area of Slack (eg. https://success.salesforce.com), please remove any test posts or accounts when you are done and refrain from engaging with actual users.\n\n\nOur Commitment to Researchers\n\n\nIf you submit a vulnerability report, the Salesforce security team and associated development organizations will use reasonable efforts to:\n\n\n\n* Respond in a timely manner, acknowledging receipt of your vulnerability report.\n* Investigate and consider your vulnerability report for eligibility under our Bug Bounty Program within 30 days of submission or less.\n* Notify you when the remediation or other action regarding the vulnerability has been implemented. \n\nSlack Products/Services In Scope for H1 Security Researchers\n\nThe Bug Bounty Program is limited to Slack products as specified within the *scope* section in HackerOne.\n\n\n\nQualifying Vulnerabilities \u0026 Bounties (In Scope)\n\n\nThe decision to grant a reward for a vulnerability report, and the value of a reward (if any), is entirely within Salesforce’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the *impact and severity* of the reported vulnerability. \n\n\n* You will qualify for consideration for a reward only if you are the first person to responsibly disclose an unknown vulnerability to us in accordance with these policies. The determination of whether you are the first person is solely within our responsibility. Vulnerabilities must also be relevant, exploitable, and well-documented in the vulnerability report. We are more likely to grant a reward if the vulnerability is specific, fixable and not currently exploited against us or our customers. \n\nOur target reward range for different types of vulnerabilities within the published scope. Additional bounty may be awarded on top of these base amounts, as determined by the Bug Bounty Management team.\n\n\n*Vulnerability Severity Definitions*\n\nThe following vulnerability severity definitions are based on internal Salesforce documentation. These definitional are a work in progress. The goal of adding these definitions to our policy is to: \n\n* Allow more efficient report triage\n* Align directly with internal Salesforce vulnerability ranking definitions\n* Remove ambiguity and subjective assignment of severity\n* Promote fair bounty payments\n* Promote researcher satisfaction\n\nIf you have feedback and/or suggestions to help us make these more clear and useful, please email your ideas to bugbountymanager@salesforce.com\n\n*Critical*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that can compromise the confidentiality, integrity, or availability of production and corporate resources and/or data with limited exploitation difficulty and/or attacker skill.\n    * Vulnerabilities that could be easily exploited by a remote or unauthenticated attacker and lead to system compromise and/or exposure of highly sensitive or customer data of any kind without requiring user interaction. \n    * Exploitation of a vulnerability that results in a root-level compromise of servers or infrastructure devices.\n* Examples include, but are not limited to:\n    * External facing remote arbitrary code execution without mitigating circumstances. \n    * External facing SQL injection. \n    * External facing unintended single tenant or cross tenant information disclosure and/or multi-tenancy break\n    * Authentication flaws resulting in arbitrary account compromise.\n    * Session management flaws leading to arbitrary account compromise. \n    * External facing credential leaks and default credential usage resulting in access to production systems containing customer data.\n    * Client and server software and system s susceptible to publicly disclosed and exploited vulnerability.\n    * Susceptibility to an external, simply executed, single actor, logic-based attacks resulting in a service outage of one or more critical systems/products.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Critical (In a small subset of cases)\n    * CVSSv3 Temporal Score: 9-10\n    * Qualys Severity 5\n    * nCircle: 1000+ (Based on risk )\n    * PCI Violating Vulnerability: Yes\n    * AppDetective: High (Based on risk )\n    * Whitehat: Urgent\n\n*High*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that can compromise the confidentiality, integrity, or availability of production and corporate resources and data.\n    * Vulnerabilities that could be easily exploited by an internal and/or external, authenticated/unauthenticated attacker and lead to system compromise and/or exposure of highly sensitive or customer data without requiring user interaction.\n    * Vulnerabilities that allow local users to gain increased privileges.\n    * Vulnerabilities that allow unauthenticated remote users to view sensitive information.\n    * Susceptibility to an external, simply executed, single actor, logic-based attacks resulting in significant performance degradation of one or more critical systems/products.\n* Examples include, but are not limited to:\n    * Privilege Escalation  \n    * External facing Persistent/Stored Cross-Site Scripting (XSS).\n    * External facing Cross-Site Request Forgery (CSRF) exposure on sensitive or critical functions.\n    * External facing stack traces containing sensitive information exposed to clients.\n    * Internal network/system use of weak cryptography that is practically exploitable in a real kill chain without nation-state resources.\n    * Internal network/system remote arbitrary code execution without mitigating circumstances.\n    * Internal network/system command or SQL injection without mitigating circumstances.\n    * Internal network/system exposure of sensitive information.\n    * Internal network/system use of default or weak credentials.\n    * Client/Server software and/or systems susceptible to publicly disclosed vulnerability.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Critical/Severe\n    * CVSSv3 Temporal Score: 7 - 8.93\n    * Qualys: Severity 44\n    * nCircle:1000 +\n    * PCI Violating Vuln: Yes\n    * AppDetective: High\n    * Whitehat: Critical\n\n*Medium*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. \n    * Vulnerabilities that could have had a critical or high impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.\n    * Susceptibility to external, simply executed, single actor, logic-based attacks resulting in some measurable performance degradation of one or more critical systems/products.\n* Examples include, but are not limited to:\n    * External unintended internal information disclosure.\n    * Internal network/application Cross-Site Scripting (XSS).\n    * Internal network/application Cross-Site Request Forgery (CSRF).\n    * Internal use of weak cryptography that is practically exploitable in a real kill chain with nation-state resources.\n    * Usage of EoL operating systems or software.\n    * External facing content spoofing.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Moderate\n    * CVSSv3 Temporal Score: 4 - 6.93\n    * Qualys: Severity 34. \n    * nCircle: 500 - 999.5. \n    * PCI Violating Vuln: No\n    * AppDetective: Medium\n    * Whitehat: High\n\n*Low*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that may be more difficult to exploit but could lead to minimal compromise of the confidentiality, integrity, or availability of resources under unlikely circumstances.\n    * These types of vulnerabilities require unlikely circumstances to be able to be exploited, or where a successful exploit would have minimal consequences.\n    * Susceptibility to external, simply executed, single actor, logic-based attacks resulting in minor performance degradation of one or more critical systems/products. \n* Examples include, but are not limited to:\n    * XSS from an authenticated customer admin\n    * Internal default pages or content without vulnerabilities such as an Apache server-status page enabled, allowing anyone browsing it to see the information of the server, as well as any request currently being made.\n    * Exposure of server config information\n    * Use of weak cryptography that is not practically exploitable in a real kill-chain.\n    * External Cross-Site Request Forgery (CSRF) exposure on non-sensitive or non-critical functions.\n    * Documentation bugs\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Moderate (Informational in nature)\n    * CVSSv3 Temporal Score: 0.1 -3.93\n    * Qualys: Severity 24\n    * nCircle: 1 -499.5.\n    * PCI Violating Vuln: No\n    * AppDetective: Low 7\n    * Whitehat: Low\n\n*Qualifying Vulnerability Descriptions*\n\n\n| Category | Description |\n| --- | --- |\n| Remote Code Execution | CWE-94: AKA \"Arbitrary Code Execution\".  Describes a security bug that allows an attacker to execute arbitrary commands or code on a target machine or in a target process. The exploit PoC may include many other vulnerability types, but ultimately the result is p0wnage of the server(s) and/or environment.  [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Disclosure of Credit Card data | CWE-359:  This is self-explanatory. Any security bug which allows disclosure of credit card information to an unauthorized user or system qualifies as Disclosure of Credit Card Data |\n| SQL Injection | CWE-1027:  SQL injection is a code injection technique in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Unrestricted XXE / File System Access | CWE-611:  External XML Entity Injection (XXE) is a specific type of Server Side Request Forgery(SSRF) which affects an XML processing engine server-side on a target. Specifically, blind XXE is when the results are either error-based or cause 3rd party interaction with services such as HTTP, FTP \u0026 DNS. An XXE attack typically occurs when XML input containing a reference to an external entity is processed by a weakly configured parser. An attacker can leverage an XXE attack to access sensitive data and read local or remote files. In a similar manner to SSRF, an attacker could introduce malicious code through Remote Code Execution (RCE).  [scr: https://blog.zsec.uk/out-of-band-xxe-2/]  [src: https://chris-young.net/2018/04/13/xxe-xml-external-entity/] |\n| Significant Authentication Bypass | CWE-305:  Authentication bypass is a vulnerability that allows an attacker access to credential protected resources without first acquiring valid credentials. Examples of this vulnerability include:* SQL injection during login to bypasses credential authentication* Direct access to resources normally beyond an authentication mechanism, such as a login screen, which do not independently validate the users authenticated session.* Failure to enumerate and enforce the systems' access policy. * A weak authentication system that allows a valid identity to be forged. | \n| Significant Authorization Bypass | CWE-285:  Authorization is the concept of allowing access to resources only to those permitted to use them. Vulnerabilities that bypass authorization checks may allow access to protected resources beyond what was intended by the system. Examples of authorization bypass include Insecure Direct Object Reference and Session Token Alteration. In each of these examples, the system trusts the users' requests because of improper or insecure implementation. |\n| Cross Instance Privilege Escalation | Salesforce is a multi-tenant platform in which \"instances\" are created for each Org. A cross-instance privilege escalation involves some user in instance A having access to data in instance B without proper authorization. |\n| Denial of Service | Susceptibility to an external, simply executed, single actor, logic-based attack resulting in a service outage or significant performance degradation of one or more critical systems/products  |\n| Disclosure of Personal Identifiable Information | CWE-200:  Personally identifiable information, or PII, is any data that could potentially be used to identify a particular person. As it relates to Salesforce, PII Disclosure bugs involve PII data stored within any in-scope platforms, excluding Salesforce Employee data such as Name and Contact information.  [src: https://www.lifelock.com/learn-identity-theft-resources-what-is-personally-identifiable-information.html] |\n| Salesforce Platform Misconfiguration and/or Custom APEX Vulnerabilities (Salesforce Owned/Controlled) | The Salesforce Platform is highly configurable, customizable, and supports custom code in the form of APEX code, Visualforce pages, etc. It is therefore capable of being misconfigured in such a way as to leak information or to otherwise be insecure. This category of vulnerability is specific to Salesforce owned and operated sites, NOT Salesforce customer-owned and operated Salesforce instances. If you identify a configuration vulnerability in a customer site please report it to that company via their Bug Bounty program or their security@\u003csome company dot com\u003e email address. There is no guarantee that the customer will respond to your email or bug submission, and it is out of Salesforce control. Please do not expect Salesforce to handle reports of customer misconfiguration.|\n| Privilege Escalation / Improper Access Control | Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in a software application to gain elevated access to resources that are normally protected from an application or user. The result is that a user with more privileges than intended by the application developer or system administrator can perform unauthorized actions. Note that Privilege Escalation is different from Permission Model Circumvention in that PE involves accessing functionality beyond that assigned to a given role, or somehow adding resource permissions to a given role without authorization, while PMC involves a complete bypass of security controls meant to enforce permissions. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access.  [src: https://en.wikipedia.org/wiki/Privilege_escalation] |\n| Non-XXE SSRF | In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.[src:https://www.owasp.org/index.php/Server_Side_Request_Forgery] |\n| Insecure Direct Object Reference | IDOR occurs when unvalidated user-supplied input is submitted and direct access to the object requested is provided. Vulnerability reports for IDOR are valid when the result is unauthorized information disclosure, modification or destruction of data, or performing a function outside of the limits of the current user. |\n| CRLF injection/HTTP response splitting  | HTTP response splitting occurs when data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. [src: https://www.owasp.org/index.php/HTTP_Response_Splitting] |\n| Circumvention of our Platform’s Permission Model | Permission Model Circumvention involves a complete bypass of security controls meant to enforce permissions. An example of PMC involves an insecurely configured system in which an API gateway fronts for several servers and implements authentication/authorization. The configuration is such that the URI to the backend servers can be identified and they are directly accessible without any additional authentication or authorization checks..While there is an authX model in place, it was trivially circumventable. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access. |\n| Cross-Site Scripting (excluding self-XSS) | CWE-80:  Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. [src:https://en.wikipedia.org/wiki/Cross-site_scripting] |\n| Cross-Site Request Forgery (CSRF) on critical actions | CWE-352:  Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.  [src: https://en.wikipedia.org/wiki/Cross-site_request_forgery] |\n| Insufficiently Protected Credentials / Credential Exposure | CWE-522:  CWE-522: Within the context of the Salesforce/HackerOne Bug Bounty program, credential exposure involves finding, or gaining access to a user or system credentials which are not meant to be public. An example of IPC would be finding a Github or other repo containing configuration files that contain usernames, passwords, API keys, private keys, etc. Another example is an exposure of a single user's credentials on the querystring, in cookies, or in other HTTP headers. |\n| Insecure/Open Redirect | CWE-601:  An HTTP parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. |\n| DNS Hijacking / Subdomain Takeover | DNS hijacking or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries.The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.  [src: https://en.wikipedia.org/wiki/DNS_hijacking] [src: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers] |\n| Configuration/Stats//Log File Exposure | CWE-532 Information Exposure Through Log Files. CWE-200: Information Exposure. Any instance in which log files or server/application configuration files are accessible when they are not meant to be. |\n| Documentation Bug | Any instance in which, from a strictly security-based perspective, the published documentation is incorrect with regard to the behavior of the product. | \n\n\nNon-Qualifying Vulnerabilities (Out of Scope)\n\n\nThe following types of issues are *specifically excluded* from our Bug Bounty Program:\n\n*Commerce Cloud Specific*\n\n* XSS that is stored in Business Manager and is reflected in the storefront / executed in a Storefront context.\n* Admin to Admin or Admin to User XSS. In these cases, a higher privileged user is attempting to attack the lower privileged user. As an admin, such script execution is considered a feature due to the nature of the platform.\n* CSRF in Storefront\n* CSRF that can only be used to make modifications on the file system\n* Session Fixation inside of Storefront\n* XSS in the following areas: HTML Editor and file upload\n* Login Page / Forgot Password Page Account Brute force or account lockout not enforced\n* Submissions regarding product deficiencies, as opposed to exploitable vulnerabilities\n\n*Other Clouds and Services (Including Commerce Cloud)*\n\n* Access control to objects and fields in Salesforce are done through permission set or profile in setup tree. If that permission or profile in the setup tree is not respected, only then it is considered as an access control issue. Please check all permissions \u0026 profiles for that particular user before filling access control bugs.\n* HTML and Link injections\n* Issues related to \"Editable Github Wiki Pages\"\n* Issues related to Salesforce *Partner* User Credential Disclosure in public code repositories such as GitHub. *Please note that this type of activity is explicitly excluded by the Conduct Guidelines in this policy.*\n* TOCTOU bugs involving platform permission changes. For example; User A has an active session, Admin reduces or increases permissions for User A, User A permissions do not change until User A logs out and back in. This is currently WAD on Salesforce platforms.\n* Invalid links from any Salesforce site to any social media site in which a claim of \"account takeover\" or \"possible phishing attacks\" are the basis for the report.\n* Bugs in content/services that are not owned/operated by Salesforce\n* Vulnerabilities affecting users of outdated or unsupported browsers or platforms\n* Vulnerabilities that have already been addressed in a product update regardless of whether the update has been applied to the publicly available research machines\n* Subdomain takeovers for out of scope domains\n* Self-XSS or XSS bugs requiring an unlikely amount of user interaction\n* XSS in our content sandbox under .content.force.com (http://content.force.com/)\n\n- XSS under \\.sitepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.livepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.visual.force.com (with the exception of Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n\n* XSS in custom apps under .force.com (with the exception of lightning.force.com and Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n\n- Bugs categorized as P3 (low risk)\n- SalesforceDX: Attacks by a root user against another user on the same machine\n- SalesforceDX: Attacks by a user on the same user\n- CSRF on forms that are available to anonymous users (e.g. web2lead contact form)\n- Clickjacking and issues only exploitable through clickjacking\n- Descriptive error messages (e.g. Stack Traces, application or server errors)\n- HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n- Fingerprinting / banner disclosure on common/public services.\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Scripting or other automation and brute-forcing of intended functionality\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n- Lack of Secure and HTTPOnly cookie flags\n- Content spoofing (text injection) or IDN homograph attacks\n- Tabnabbing \n- Email configuration issues (SPF, DKIM, DMARC)\n- Weak Captcha / Captcha Bypass\n- Forced Login / Logout CSRF\n- Account lockout, Login or Forgot Password page brute force\n- Password complexity or account recovery policies\n- Username / email enumeration (brute force)\n- HTTPS Mixed Content\n- Missing HTTP security headers, specifically: Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy.\n- OPTIONS HTTP method enabled\n- Known SSL issues (e.g. attacks such as BEAST, BREACH, POODLE, TLS Renegotiation)\n- SSL Forward Secrecy or HSTS not enabled\n- Weak SSL/TLS Cipher Suites\n- CSV Excel Formula injection\n- Issues related to networking protocols or industry standards not controlled by Salesforce\n- Sending vulnerability reports using automated tools without validation\n- Use of a known-vulnerable library without evidence of exploitability\n- Problems related to widely publicized CVE's\n- Attacks requiring physical access to a user's unlocked device\n- Reports of spam, phishing or security best practices\n- Reflected XSS involving Adobe Flash files (.swf)\n\n*If you are unsure whether a bug or issue that you discover in a participating service is a non-qualifying vulnerability, please email us at \u003cbugbountymanager@salesforce.com\u003e*\n\n\n_Intellectual Property_\n\n\nParticipating in the Bug Bounty Program does not grant to you or any other third party any rights to any Slack or Salesforce intellectual property, product or service. All rights not otherwise granted herein are expressly reserved. Whether or not we grant you a reward, you hereby assign to Salesforce all right, title and interest (including all intellectual property rights), in the contents of all vulnerability reports that you submit to Salesforce. \n\nBy participating in the Bug Bounty Program, you represent that you have the right to assign all such right, title and interest to us and that your participation in the Bug Bounty Program and assignment of such right, title and interest will not breach any agreement you may have with a third party (e.g. your employer).\n\n\n_Other Terms and Conditions_\n\n\nSalesforce pledges not to pursue a civil action or initiate a complaint to law enforcement against researchers for security research and vulnerability disclosure activities conducted in accordance with this Policy. We consider security research and vulnerability disclosure activities conducted in accordance with this Policy “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA and applicable anti-hacking laws such as Cal. Penal Code 502(c). We waive any DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy.\n\nBy participating in the Bug Bounty Program, you agree to be bound by these rules. These policies will apply to you in addition to, and will not replace, any other terms and conditions that are imposed by HackerOne.\n\n- Your participation in the Bug Bounty Program does not create any kind of employment relationship or partnership between you and Salesforce. You must not hold yourself out as a Salesforce employee or as someone in any way affiliated with Salesforce.\n- You must comply with all applicable laws in connection with your participation in this program. \n- You are responsible for any applicable taxes associated with any reward you receive. \n- Vulnerability reports received prior to the Bug Bounty Program launch are not eligible for rewards and may not be re-submitted for a reward.\n- You will not use any of our trademarks, service marks and logos.\n- We may modify this Policy at any time by posting an updated version of this document.\n- We may terminate this Bug Bounty Program at any time without notice. \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":[],"timestamp":"2022-02-03T21:08:41.389Z"},{"id":3666097,"new_policy":"## Slack Technologies, LLC, a Salesforce company.\n\nOver _$12M_ in bounties awarded across all our H1 Bug Bounty programs since 2015!\n\n\nAt Slack, a Salesforce company, Trust is our #1 value and we take the protection of our customers' data very seriously. As a result, we encourage responsible reporting and disclosure of any vulnerabilities that may be found on our websites, APIs, or applications. \n\nSlack is committed to working with security researchers to verify and address any potential vulnerabilities that are reported to us. If you want to help us make our products safer with the possibility of a reward in the process, you are in the right place!\n\nPlease review these terms before you test and/or report a vulnerability. Slack pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.\n\nEligibility for the Bug Bounty Program \n\n\nUnder our Bug Bounty Program, qualified individuals are encouraged to submit bug reports that detail existing vulnerabilities in certain in-scope Salesforce products and services. In certain circumstances, Salesforce may grant monetary rewards to those who submit vulnerability reports.\n\nWe are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Slack. However, only those researchers that meet the following criteria may be eligible to receive a reward. Some of the requirements to participate in the Bug Bounty Program include:\n\n\n* You must be the first reporter of a vulnerability associated with a participating service (we will also not reward for a known vulnerability which we are actively fixing)\n* You must have personally discovered the vulnerability and you may not report a vulnerability that was discovered by another person (including, and especially, someone who does not qualify to participate in the Bug Bounty Program)\n* You must not be employed by Slack, Salesforce, its subsidiaries, or any related entities, currently or in the last 12 months.\n* You must comply with this Policy when discovering the vulnerability and submitting the vulnerability report\n* Slack or H1 can’t be legally prohibited from rewarding you for any reason\n* You must conduct all vulnerability testing against non-production Developer or Trial Edition instances of the participating sites (listed in scope) and services (listed below). Testing against real, production systems, or partner implementations, is strictly prohibited. All Developer or Trial Edition instances of the participating sites typically have the same release of code. Preview instances of in-scope sites and services are also in scope.\n\nConduct Guidelines\n\n\nWhile we encourage you to discover and report to us any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited and will result in disqualification from the Bug Bounty Program:\n\n\n* Disclosing any vulnerabilities or suspected vulnerabilities you discover to any other person without explicit Salesforce authorization\n* Disclosing the contents of any submission to our program without explicit Slack authorization\n* Accessing private information of any person stored on a Slack product or service – You must use test accounts\n* Accessing sensitive information (e.g., credentials)\n* Performing actions that may negatively affect Salesforce system performance or its users (e.g. Spam, Phishing, Brute force, Distributed Denial of Service (DDoS))\n* Conducting any kind of physical attack on Slack personnel, property or data centers\n* Social engineering any Slack employee or contractor\n* Conduct vulnerability testing of participating services using anything other than test accounts (e.g. Developer or Trial Edition instances)\n* Exfiltrating data. Please test only the minimum necessary to validate a vulnerability (we can verify if data exfiltration would be possible from a vulnerability, and will reward with the impact in mind)\n* Violating any laws or breaching any agreements in order to discover vulnerabilities\n\nIf you are testing a publicly viewable area of Slack (eg. https://success.salesforce.com), please remove any test posts or accounts when you are done and refrain from engaging with actual users.\n\n\nOur Commitment to Researchers\n\n\nIf you submit a vulnerability report, the Salesforce security team and associated development organizations will use reasonable efforts to:\n\n\n\n* Respond in a timely manner, acknowledging receipt of your vulnerability report.\n* Investigate and consider your vulnerability report for eligibility under our Bug Bounty Program within 30 days of submission or less.\n* Notify you when the remediation or other action regarding the vulnerability has been implemented. \n\nSlack Products/Services In Scope for H1 Security Researchers\n\nThe Bug Bounty Program is limited to Slack products as specified within the *scope* section in HackerOne.\n\n\n\nQualifying Vulnerabilities \u0026 Bounties (In Scope)\n\n\nThe decision to grant a reward for a vulnerability report, and the value of a reward (if any), is entirely within Salesforce’s discretion. If we decide to offer a reward for a vulnerability report, the value of the reward will usually be based on the *impact and severity* of the reported vulnerability. \n\n\n* You will qualify for consideration for a reward only if you are the first person to responsibly disclose an unknown vulnerability to us in accordance with these policies. The determination of whether you are the first person is solely within our responsibility. Vulnerabilities must also be relevant, exploitable, and well-documented in the vulnerability report. We are more likely to grant a reward if the vulnerability is specific, fixable and not currently exploited against us or our customers. \n\nOur target reward range for different types of vulnerabilities within the published scope. Additional bounty may be awarded on top of these base amounts, as determined by the Bug Bounty Management team.\n\n\n*Vulnerability Severity Definitions*\n\nThe following vulnerability severity definitions are based on internal Salesforce documentation. These definitional are a work in progress. The goal of adding these definitions to our policy is to: \n\n* Allow more efficient report triage\n* Align directly with internal Salesforce vulnerability ranking definitions\n* Remove ambiguity and subjective assignment of severity\n* Promote fair bounty payments\n* Promote researcher satisfaction\n\nIf you have feedback and/or suggestions to help us make these more clear and useful, please email your ideas to bugbountymanager@salesforce.com\n\n*Critical*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that can compromise the confidentiality, integrity, or availability of production and corporate resources and/or data with limited exploitation difficulty and/or attacker skill.\n    * Vulnerabilities that could be easily exploited by a remote or unauthenticated attacker and lead to system compromise and/or exposure of highly sensitive or customer data of any kind without requiring user interaction. \n    * Exploitation of a vulnerability that results in a root-level compromise of servers or infrastructure devices.\n* Examples include, but are not limited to:\n    * External facing remote arbitrary code execution without mitigating circumstances. \n    * External facing SQL injection. \n    * External facing unintended single tenant or cross tenant information disclosure and/or multi-tenancy break\n    * Authentication flaws resulting in arbitrary account compromise.\n    * Session management flaws leading to arbitrary account compromise. \n    * External facing credential leaks and default credential usage resulting in access to production systems containing customer data.\n    * Client and server software and system s susceptible to publicly disclosed and exploited vulnerability.\n    * Susceptibility to an external, simply executed, single actor, logic-based attacks resulting in a service outage of one or more critical systems/products.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Critical (In a small subset of cases)\n    * CVSSv3 Temporal Score: 9-10\n    * Qualys Severity 5\n    * nCircle: 1000+ (Based on risk )\n    * PCI Violating Vulnerability: Yes\n    * AppDetective: High (Based on risk )\n    * Whitehat: Urgent\n\n*High*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that can compromise the confidentiality, integrity, or availability of production and corporate resources and data.\n    * Vulnerabilities that could be easily exploited by an internal and/or external, authenticated/unauthenticated attacker and lead to system compromise and/or exposure of highly sensitive or customer data without requiring user interaction.\n    * Vulnerabilities that allow local users to gain increased privileges.\n    * Vulnerabilities that allow unauthenticated remote users to view sensitive information.\n    * Susceptibility to an external, simply executed, single actor, logic-based attacks resulting in significant performance degradation of one or more critical systems/products.\n* Examples include, but are not limited to:\n    * Privilege Escalation  \n    * External facing Persistent/Stored Cross-Site Scripting (XSS).\n    * External facing Cross-Site Request Forgery (CSRF) exposure on sensitive or critical functions.\n    * External facing stack traces containing sensitive information exposed to clients.\n    * Internal network/system use of weak cryptography that is practically exploitable in a real kill chain without nation-state resources.\n    * Internal network/system remote arbitrary code execution without mitigating circumstances.\n    * Internal network/system command or SQL injection without mitigating circumstances.\n    * Internal network/system exposure of sensitive information.\n    * Internal network/system use of default or weak credentials.\n    * Client/Server software and/or systems susceptible to publicly disclosed vulnerability.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Critical/Severe\n    * CVSSv3 Temporal Score: 7 - 8.93\n    * Qualys: Severity 44\n    * nCircle:1000 +\n    * PCI Violating Vuln: Yes\n    * AppDetective: High\n    * Whitehat: Critical\n\n*Medium*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. \n    * Vulnerabilities that could have had a critical or high impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.\n    * Susceptibility to external, simply executed, single actor, logic-based attacks resulting in some measurable performance degradation of one or more critical systems/products.\n* Examples include, but are not limited to:\n    * External unintended internal information disclosure.\n    * Internal network/application Cross-Site Scripting (XSS).\n    * Internal network/application Cross-Site Request Forgery (CSRF).\n    * Internal use of weak cryptography that is practically exploitable in a real kill chain with nation-state resources.\n    * Usage of EoL operating systems or software.\n    * External facing content spoofing.\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Moderate\n    * CVSSv3 Temporal Score: 4 - 6.93\n    * Qualys: Severity 34. \n    * nCircle: 500 - 999.5. \n    * PCI Violating Vuln: No\n    * AppDetective: Medium\n    * Whitehat: High\n\n*Low*\n\n\n* Severity level includes but is not limited to:\n    * Vulnerabilities that may be more difficult to exploit but could lead to minimal compromise of the confidentiality, integrity, or availability of resources under unlikely circumstances.\n    * These types of vulnerabilities require unlikely circumstances to be able to be exploited, or where a successful exploit would have minimal consequences.\n    * Susceptibility to external, simply executed, single actor, logic-based attacks resulting in minor performance degradation of one or more critical systems/products. \n* Examples include, but are not limited to:\n    * XSS from an authenticated customer admin\n    * Internal default pages or content without vulnerabilities such as an Apache server-status page enabled, allowing anyone browsing it to see the information of the server, as well as any request currently being made.\n    * Exposure of server config information\n    * Use of weak cryptography that is not practically exploitable in a real kill-chain.\n    * External Cross-Site Request Forgery (CSRF) exposure on non-sensitive or non-critical functions.\n    * Documentation bugs\n* Tooling Score Estimates include, but are not limited to:\n    * Nessus: Moderate (Informational in nature)\n    * CVSSv3 Temporal Score: 0.1 -3.93\n    * Qualys: Severity 24\n    * nCircle: 1 -499.5.\n    * PCI Violating Vuln: No\n    * AppDetective: Low 7\n    * Whitehat: Low\n\n*Qualifying Vulnerability Descriptions*\n\n\n| Category | Description |\n| --- | --- |\n| Remote Code Execution | CWE-94: AKA \"Arbitrary Code Execution\".  Describes a security bug that allows an attacker to execute arbitrary commands or code on a target machine or in a target process. The exploit PoC may include many other vulnerability types, but ultimately the result is p0wnage of the server(s) and/or environment.  [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Disclosure of Credit Card data | CWE-359:  This is self-explanatory. Any security bug which allows disclosure of credit card information to an unauthorized user or system qualifies as Disclosure of Credit Card Data |\n| SQL Injection | CWE-1027:  SQL injection is a code injection technique in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. [src: https://en.wikipedia.org/wiki/SQL_injection] |\n| Unrestricted XXE / File System Access | CWE-611:  External XML Entity Injection (XXE) is a specific type of Server Side Request Forgery(SSRF) which affects an XML processing engine server-side on a target. Specifically, blind XXE is when the results are either error-based or cause 3rd party interaction with services such as HTTP, FTP \u0026 DNS. An XXE attack typically occurs when XML input containing a reference to an external entity is processed by a weakly configured parser. An attacker can leverage an XXE attack to access sensitive data and read local or remote files. In a similar manner to SSRF, an attacker could introduce malicious code through Remote Code Execution (RCE).  [scr: https://blog.zsec.uk/out-of-band-xxe-2/]  [src: https://chris-young.net/2018/04/13/xxe-xml-external-entity/] |\n| Significant Authentication Bypass | CWE-305:  Authentication bypass is a vulnerability that allows an attacker access to credential protected resources without first acquiring valid credentials. Examples of this vulnerability include:* SQL injection during login to bypasses credential authentication* Direct access to resources normally beyond an authentication mechanism, such as a login screen, which do not independently validate the users authenticated session.* Failure to enumerate and enforce the systems' access policy. * A weak authentication system that allows a valid identity to be forged. | \n| Significant Authorization Bypass | CWE-285:  Authorization is the concept of allowing access to resources only to those permitted to use them. Vulnerabilities that bypass authorization checks may allow access to protected resources beyond what was intended by the system. Examples of authorization bypass include Insecure Direct Object Reference and Session Token Alteration. In each of these examples, the system trusts the users' requests because of improper or insecure implementation. |\n| Cross Instance Privilege Escalation | Salesforce is a multi-tenant platform in which \"instances\" are created for each Org. A cross-instance privilege escalation involves some user in instance A having access to data in instance B without proper authorization. |\n| Denial of Service | Susceptibility to an external, simply executed, single actor, logic-based attack resulting in a service outage or significant performance degradation of one or more critical systems/products  |\n| Disclosure of Personal Identifiable Information | CWE-200:  Personally identifiable information, or PII, is any data that could potentially be used to identify a particular person. As it relates to Salesforce, PII Disclosure bugs involve PII data stored within any in-scope platforms, excluding Salesforce Employee data such as Name and Contact information.  [src: https://www.lifelock.com/learn-identity-theft-resources-what-is-personally-identifiable-information.html] |\n| Salesforce Platform Misconfiguration and/or Custom APEX Vulnerabilities (Salesforce Owned/Controlled) | The Salesforce Platform is highly configurable, customizable, and supports custom code in the form of APEX code, Visualforce pages, etc. It is therefore capable of being misconfigured in such a way as to leak information or to otherwise be insecure. This category of vulnerability is specific to Salesforce owned and operated sites, NOT Salesforce customer-owned and operated Salesforce instances. If you identify a configuration vulnerability in a customer site please report it to that company via their Bug Bounty program or their security@\u003csome company dot com\u003e email address. There is no guarantee that the customer will respond to your email or bug submission, and it is out of Salesforce control. Please do not expect Salesforce to handle reports of customer misconfiguration.|\n| Privilege Escalation / Improper Access Control | Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in a software application to gain elevated access to resources that are normally protected from an application or user. The result is that a user with more privileges than intended by the application developer or system administrator can perform unauthorized actions. Note that Privilege Escalation is different from Permission Model Circumvention in that PE involves accessing functionality beyond that assigned to a given role, or somehow adding resource permissions to a given role without authorization, while PMC involves a complete bypass of security controls meant to enforce permissions. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access.  [src: https://en.wikipedia.org/wiki/Privilege_escalation] |\n| Non-XXE SSRF | In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases or perform post requests towards internal services which are not intended to be exposed.[src:https://www.owasp.org/index.php/Server_Side_Request_Forgery] |\n| Insecure Direct Object Reference | IDOR occurs when unvalidated user-supplied input is submitted and direct access to the object requested is provided. Vulnerability reports for IDOR are valid when the result is unauthorized information disclosure, modification or destruction of data, or performing a function outside of the limits of the current user. |\n| CRLF injection/HTTP response splitting  | HTTP response splitting occurs when data enters a web application through an untrusted source, most frequently an HTTP request. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. [src: https://www.owasp.org/index.php/HTTP_Response_Splitting] |\n| Circumvention of our Platform’s Permission Model | Permission Model Circumvention involves a complete bypass of security controls meant to enforce permissions. An example of PMC involves an insecurely configured system in which an API gateway fronts for several servers and implements authentication/authorization. The configuration is such that the URI to the backend servers can be identified and they are directly accessible without any additional authentication or authorization checks..While there is an authX model in place, it was trivially circumventable. Ultimately, PE involves a user within the system increasing their access somehow, while PMC involves an anonymous user gaining access. |\n| Cross-Site Scripting (excluding self-XSS) | CWE-80:  Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. [src:https://en.wikipedia.org/wiki/Cross-site_scripting] |\n| Cross-Site Request Forgery (CSRF) on critical actions | CWE-352:  Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.  [src: https://en.wikipedia.org/wiki/Cross-site_request_forgery] |\n| Insufficiently Protected Credentials / Credential Exposure | CWE-522:  CWE-522: Within the context of the Salesforce/HackerOne Bug Bounty program, credential exposure involves finding, or gaining access to a user or system credentials which are not meant to be public. An example of IPC would be finding a Github or other repo containing configuration files that contain usernames, passwords, API keys, private keys, etc. Another example is an exposure of a single user's credentials on the querystring, in cookies, or in other HTTP headers. |\n| Insecure/Open Redirect | CWE-601:  An HTTP parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. |\n| DNS Hijacking / Subdomain Takeover | DNS hijacking or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries.The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.  [src: https://en.wikipedia.org/wiki/DNS_hijacking] [src: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers] |\n| Configuration/Stats//Log File Exposure | CWE-532 Information Exposure Through Log Files. CWE-200: Information Exposure. Any instance in which log files or server/application configuration files are accessible when they are not meant to be. |\n| Documentation Bug | Any instance in which, from a strictly security-based perspective, the published documentation is incorrect with regard to the behavior of the product. | \n\n\nNon-Qualifying Vulnerabilities (Out of Scope)\n\n\nThe following types of issues are *specifically excluded* from our Bug Bounty Program:\n\n*Commerce Cloud Specific*\n\n* XSS that is stored in Business Manager and is reflected in the storefront / executed in a Storefront context.\n* Admin to Admin or Admin to User XSS. In these cases, a higher privileged user is attempting to attack the lower privileged user. As an admin, such script execution is considered a feature due to the nature of the platform.\n* CSRF in Storefront\n* CSRF that can only be used to make modifications on the file system\n* Session Fixation inside of Storefront\n* XSS in the following areas: HTML Editor and file upload\n* Login Page / Forgot Password Page Account Brute force or account lockout not enforced\n* Submissions regarding product deficiencies, as opposed to exploitable vulnerabilities\n\n*Other Clouds and Services (Including Commerce Cloud)*\n\n* Access control to objects and fields in Salesforce are done through permission set or profile in setup tree. If that permission or profile in the setup tree is not respected, only then it is considered as an access control issue. Please check all permissions \u0026 profiles for that particular user before filling access control bugs.\n* HTML and Link injections\n* Issues related to \"Editable Github Wiki Pages\"\n* Issues related to Salesforce *Partner* User Credential Disclosure in public code repositories such as GitHub. *Please note that this type of activity is explicitly excluded by the Conduct Guidelines in this policy.*\n* TOCTOU bugs involving platform permission changes. For example; User A has an active session, Admin reduces or increases permissions for User A, User A permissions do not change until User A logs out and back in. This is currently WAD on Salesforce platforms.\n* Invalid links from any Salesforce site to any social media site in which a claim of \"account takeover\" or \"possible phishing attacks\" are the basis for the report.\n* Bugs in content/services that are not owned/operated by Salesforce\n* Vulnerabilities affecting users of outdated or unsupported browsers or platforms\n* Vulnerabilities that have already been addressed in a product update regardless of whether the update has been applied to the publicly available research machines\n* Subdomain takeovers for out of scope domains\n* Self-XSS or XSS bugs requiring an unlikely amount of user interaction\n* XSS in our content sandbox under .content.force.com (http://content.force.com/)\n\n- XSS under \\.sitepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.livepreview.(na\\/gus).force.com (http://force.com/)\n- XSS under \\.visual.force.com (with the exception of Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n\n* XSS in custom apps under .force.com (with the exception of lightning.force.com and Salesforce developed and maintained apps like LiveMessage, Agile Accelerator, Private Appexchange, etc.)\n\n- Bugs categorized as P3 (low risk)\n- SalesforceDX: Attacks by a root user against another user on the same machine\n- SalesforceDX: Attacks by a user on the same user\n- CSRF on forms that are available to anonymous users (e.g. web2lead contact form)\n- Clickjacking and issues only exploitable through clickjacking\n- Descriptive error messages (e.g. Stack Traces, application or server errors)\n- HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n- Fingerprinting / banner disclosure on common/public services.\n- Disclosure of known public files or directories, (e.g. robots.txt)\n- Scripting or other automation and brute-forcing of intended functionality\n- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n- Lack of Secure and HTTPOnly cookie flags\n- Content spoofing (text injection) or IDN homograph attacks\n- Tabnabbing \n- Email configuration issues (SPF, DKIM, DMARC)\n- Weak Captcha / Captcha Bypass\n- Forced Login / Logout CSRF\n- Account lockout, Login or Forgot Password page brute force\n- Password complexity or account recovery policies\n- Username / email enumeration (brute force)\n- HTTPS Mixed Content\n- Missing HTTP security headers, specifically: Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Content-Security-Policy.\n- OPTIONS HTTP method enabled\n- Known SSL issues (e.g. attacks such as BEAST, BREACH, POODLE, TLS Renegotiation)\n- SSL Forward Secrecy or HSTS not enabled\n- Weak SSL/TLS Cipher Suites\n- CSV Excel Formula injection\n- Issues related to networking protocols or industry standards not controlled by Salesforce\n- Sending vulnerability reports using automated tools without validation\n- Use of a known-vulnerable library without evidence of exploitability\n- Problems related to widely publicized CVE's\n- Attacks requiring physical access to a user's unlocked device\n- Reports of spam, phishing or security best practices\n- Reflected XSS involving Adobe Flash files (.swf)\n\n*If you are unsure whether a bug or issue that you discover in a participating service is a non-qualifying vulnerability, please email us at \u003cbugbountymanager@salesforce.com\u003e*\n\n\n_Intellectual Property_\n\n\nParticipating in the Bug Bounty Program does not grant to you or any other third party any rights to any Slack or Salesforce intellectual property, product or service. All rights not otherwise granted herein are expressly reserved. Whether or not we grant you a reward, you hereby assign to Salesforce all right, title and interest (including all intellectual property rights), in the contents of all vulnerability reports that you submit to Salesforce. \n\nBy participating in the Bug Bounty Program, you represent that you have the right to assign all such right, title and interest to us and that your participation in the Bug Bounty Program and assignment of such right, title and interest will not breach any agreement you may have with a third party (e.g. your employer).\n\n\n_Other Terms and Conditions_\n\n\nSalesforce pledges not to pursue a civil action or initiate a complaint to law enforcement against researchers for security research and vulnerability disclosure activities conducted in accordance with this Policy. We consider security research and vulnerability disclosure activities conducted in accordance with this Policy “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA and applicable anti-hacking laws such as Cal. Penal Code 502(c). We waive any DMCA claim against you for circumventing the technological measures we have used to protect the applications in scope. If legal action is initiated by a third party against you and you have complied with this Policy, we will take steps to make it known that your actions were conducted in compliance with this Policy.\n\nBy participating in the Bug Bounty Program, you agree to be bound by these rules. These policies will apply to you in addition to, and will not replace, any other terms and conditions that are imposed by HackerOne.\n\n- Your participation in the Bug Bounty Program does not create any kind of employment relationship or partnership between you and Salesforce. You must not hold yourself out as a Salesforce employee or as someone in any way affiliated with Salesforce.\n- You must comply with all applicable laws in connection with your participation in this program. \n- You are responsible for any applicable taxes associated with any reward you receive. \n- Vulnerability reports received prior to the Bug Bounty Program launch are not eligible for rewards and may not be re-submitted for a reward.\n- You will not use any of our trademarks, service marks and logos.\n- We may modify this Policy at any time by posting an updated version of this document.\n- We may terminate this Bug Bounty Program at any time without notice. \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":[],"timestamp":"2022-02-03T21:07:09.251Z"},{"id":3657074,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties following our triage process, and will keep you posted as we work to verify submissions.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n|Severity | Critical  | High | Medium | Low |\n| ------------- | ------------- | ------------- | ------------- | ------------- |\n| CVSSv3 | 9.0 - 10.0 | 7.0 - 8.9 | 4.0 - 6.9 | 2.0 - 3.9 |\n| Min/Max | $5000 | $2500 | $1000  | $250 |\n\n## Tier 3: Low Severity Bugs    $250 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $1000 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $2500  and up\n* XSS\n\n## Tier 0: Critical Severity Bugs $5000 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* slackb.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n    * Nebula (https://github.com/slackhq/nebula)\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on WordPress, so if you find vulnerabilities in the WordPress service, please see [WordPress bounty program](https://hackerone.com/wordpress) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* EMM client vulnerabilities in the absence of a valid MDM configuration via a supported MDM provider, (such as MobileIron), on an EMM-enabled Slack team\n* Submissions from former Slack employees within one year of their departure from Slack\n* Bugs in Slack’s public GitHub repos besides Tier-0 issues in Nebula. Others should be submitted through GitHub’s Issues mechanism.\n\n# Safe Harbor \nAny activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. \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":"2021-08-18T19:43:34.109Z"},{"id":3653461,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties following our triage process, and will keep you posted as we work to verify submissions.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n|Severity | Critical  | High | Medium | Low |\n| ------------- | ------------- | ------------- | ------------- | ------------- |\n| CVSSv3 | 9.0 - 10.0 | 7.0 - 8.9 | 4.0 - 6.9 | 2.0 - 3.9 |\n| Min/Max | $5000 | $2500 | $1000  | $250 |\n\n## Tier 3: Low Severity Bugs    $250 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $1000 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $2500  and up\n* XSS\n\n## Tier 0: Critical Severity Bugs $5000 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* slackb.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n    * Nebula (https://github.com/slackhq/nebula)\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on WordPress, so if you find vulnerabilities in the WordPress service, please see [WordPress bounty program](https://hackerone.com/wordpress) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* EMM client vulnerabilities in the absence of a valid MDM configuration via a supported MDM provider, (such as MobileIron), on an EMM-enabled Slack team\n* Submissions from former Slack employees within one year of their departure from Slack\n\n# Safe Harbor \nAny activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. \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":"2021-06-14T17:16:50.284Z"},{"id":3646997,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n|Severity | Critical  | High | Medium | Low |\n| ------------- | ------------- | ------------- | ------------- | ------------- |\n| CVSSv3 | 9.0 - 10.0 | 7.0 - 8.9 | 4.0 - 6.9 | 2.0 - 3.9 |\n| Min/Max | $5000 | $2500 | $1000  | $250 |\n\n## Tier 3: Low Severity Bugs    $250 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $1000 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $2500  and up\n* XSS\n\n## Tier 0: Critical Severity Bugs $5000 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* slackb.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n    * Nebula (https://github.com/slackhq/nebula)\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on WordPress, so if you find vulnerabilities in the WordPress service, please see [WordPress bounty program](https://hackerone.com/wordpress) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* EMM\n* Submissions from former Slack employees within one year of their departure from Slack\n\n# Safe Harbor \nAny activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. \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-12-18T00:30:20.239Z"},{"id":3641852,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n|Severity | Critical  | High | Medium | Low |\n| ------------- | ------------- | ------------- | ------------- | ------------- |\n| CVSSv3 | 9.0 - 10.0 | 7.0 - 8.9 | 4.0 - 6.9 | 2.0 - 3.9 |\n| Min/Max | $1,500 | $1,000 | $500  | $100 |\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000  and up\n* XSS\n\n## Tier 0: Critical Severity Bugs $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* slackb.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n    * Nebula (https://github.com/slackhq/nebula)\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on WordPress, so if you find vulnerabilities in the WordPress service, please see [WordPress bounty program](https://hackerone.com/wordpress) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* EMM\n* Submissions from former Slack employees within one year of their departure from Slack\n\n# Safe Harbor \nAny activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. \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-08-30T14:03:28.149Z"},{"id":3641090,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n|Severity | Critical  | High | Medium | Low |\n| ------------- | ------------- | ------------- | ------------- | ------------- |\n| CVSSv3 | 9.0 - 10.0 | 7.0 - 8.9 | 4.0 - 6.9 | 2.0 - 3.9 |\n| Min/Max | $1,500 | $1,000 | $500  | $100 |\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    ~~$1000~~ $2500 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  ~~$1500~~ $5000 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* slackb.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n    * Nebula (https://github.com/slackhq/nebula)\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on WordPress, so if you find vulnerabilities in the WordPress service, please see [WordPress bounty program](https://hackerone.com/wordpress) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* EMM\n* Submissions from former Slack employees within one year of their departure from Slack\n\n# Safe Harbor \nAny activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. \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-08-07T21:16:17.786Z"},{"id":3636913,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n# Bounty Promotion Running May 1, 2020 - July 31, 2020\n|Severity | Critical  | High | Medium | Low |\n| ------------- | ------------- | ------------- | ------------- | ------------- |\n| CVSSv3 | 9.0 - 10.0 | 7.0 - 8.9 | 4.0 - 6.9 | 2.0 - 3.9 |\n| Min | ~~$1,500~~ $5,000 | ~~$1,000~~ $2,500 | $500  | $100 |\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    ~~$1000~~ $2500 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  ~~$1500~~ $5000 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* slackb.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n    * Nebula (https://github.com/slackhq/nebula)\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on WordPress, so if you find vulnerabilities in the WordPress service, please see [WordPress bounty program](https://hackerone.com/wordpress) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* EMM\n* Submissions from former Slack employees within one year of their departure from Slack\n\n# Safe Harbor \nAny activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. \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-06-01T20:15:19.246Z"},{"id":3635748,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n# Bounty Promotion Running May 1, 2020 - July 31, 2020\n|Severity | Critical  | High | Medium | Low |\n| ------------- | ------------- | ------------- | ------------- | ------------- |\n| CVSSv3 | 9.0 - 10.0 | 7.0 - 8.9 | 4.0 - 6.9 | 2.0 - 3.9 |\n| Min/Max | ~~$1,500~~ $5,000 | ~~$1,000~~ $2,500 | $500  | $100 |\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    ~~$1000~~ $2500 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  ~~$1500~~ $5000 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* slackb.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n    * Nebula (https://github.com/slackhq/nebula)\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on WordPress, so if you find vulnerabilities in the WordPress service, please see [WordPress bounty program](https://hackerone.com/wordpress) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* EMM\n* Submissions from former Slack employees within one year of their departure from Slack\n\n# Safe Harbor \nAny activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. \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-05-01T21:22:32.122Z"},{"id":3635745,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n# Bounty Promotion Running May 1, 2020 - July 31, 2020\n|Severity | Critical  | High | Medium | Low |\n| ------------- | ------------- | ------------- | ------------- | ------------- |\n| CVSSv3 | 9.0 - 10.0 | 7.0 - 8.9 | 4.0 - 6.9 | 2.0 - 3.9 |\n| Min/Max | ~~$1,500~~ $5,000 | ~~$1,000~~ $2,500 | $500  | $100 |\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    ~~$1000~~ $2500 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  ~~$1500~~ $5000 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* slackb.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n    * Nebula (https://github.com/slackhq/nebula)\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on WordPress, so if you find vulnerabilities in the WordPress service, please see [WordPress bounty program](https://hackerone.com/wordpress) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* EMM\n* Submissions from former Slack employees within one year of their departure from Slack\n\n# Safe Harbor \nAny activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. \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-05-01T20:49:44.546Z"},{"id":3635744,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n-# Bounty Promotion Running May 1, 2020 - July 31, 2020\n|Severity | Critical  | High | Medium | Low |\n| ------------- | ------------- | ------------- | ------------- | ------------- |\n| CVSSv3 | 9.0 - 10.0 | 7.0 - 8.9 | 4.0 - 6.9 | 2.0 - 3.9 |\n| Min/Max | -$1,500- $5,000 | -$1,000- $2,500 | $500  | $100 |\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    -$1000- $2500 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  -$1500- $5000 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* slackb.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n    * Nebula (https://github.com/slackhq/nebula)\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on WordPress, so if you find vulnerabilities in the WordPress service, please see [WordPress bounty program](https://hackerone.com/wordpress) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* EMM\n* Submissions from former Slack employees within one year of their departure from Slack\n\n# Safe Harbor \nAny activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. \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-05-01T20:46:32.559Z"},{"id":3634772,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n|Severity | Critical  | High | Medium | Low |\n| ------------- | ------------- | ------------- | ------------- | ------------- |\n| CVSSv3 | 9.0 - 10.0 | 7.0 - 8.9 | 4.0 - 6.9 | 2.0 - 3.9 |\n| Min/Max | $1,500 | $1,000 | $500  | $100 |\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* slackb.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n    * Nebula (https://github.com/slackhq/nebula)\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on WordPress, so if you find vulnerabilities in the WordPress service, please see [WordPress bounty program](https://hackerone.com/wordpress) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* EMM\n* Submissions from former Slack employees within one year of their departure from Slack\n\n# Safe Harbor \nAny activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. \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-04-08T16:23:39.066Z"},{"id":3625104,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n# Bounty Promotion Running October 28th - November 27th \n|Severity | Critical  | High | Medium | Low |\n| ------------- | ------------- | ------------- | ------------- | ------------- |\n| CVSSv3 | 9.0 - 10.0 | 7.0 - 8.9 | 4.0 - 6.9 | 2.0 - 3.9 |\n| Min/Max | $1,500 | $1,000 | $500  | $100 |\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* slackb.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n    * Nebula (https://github.com/slackhq/nebula)\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on WordPress, so if you find vulnerabilities in the WordPress service, please see [WordPress bounty program](https://hackerone.com/wordpress) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* EMM\n* Submissions from former Slack employees within one year of their departure from Slack\n\n# Safe Harbor \nAny activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. \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":"2019-12-03T19:05:13.553Z"},{"id":3624262,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n# Bounty Promotion Running October 28th - November 27th \n|Severity | Critical  | High | Medium | Low |\n| ------------- | ------------- | ------------- | ------------- | ------------- |\n| CVSSv3 | 9.0 - 10.0 | 7.0 - 8.9 | 4.0 - 6.9 | 2.0 - 3.9 |\n| Min/Max | ~~$1,500~~ - $5,000 | ~~$1,000~~ - $2,500 | $500  | $100 |\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* slackb.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n    * Nebula (https://github.com/slackhq/nebula)\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on WordPress, so if you find vulnerabilities in the WordPress service, please see [WordPress bounty program](https://hackerone.com/wordpress) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* EMM\n* Submissions from former Slack employees within one year of their departure from Slack\n\n# Safe Harbor \nAny activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. \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":"2019-11-21T19:48:26.838Z"},{"id":3622398,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n# Bounty Promotion Running October 28th - November 27th \n|Severity | Critical  | High | Medium | Low |\n| ------------- | ------------- | ------------- | ------------- | ------------- |\n| CVSSv3 | 9.0 - 10.0 | 7.0 - 8.9 | 4.0 - 6.9 | 2.0 - 3.9 |\n| Min/Max | ~~$1,500~~ - $5,000 | ~~$1,000~~ - $2,500 | $500  | $100 |\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* slackb.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on WordPress, so if you find vulnerabilities in the WordPress service, please see [WordPress bounty program](https://hackerone.com/wordpress) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* EMM\n* Submissions from former Slack employees within one year of their departure from Slack\n\n# Safe Harbor \nAny activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. \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":"2019-10-28T16:01:58.735Z"},{"id":3618777,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* slackb.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on WordPress, so if you find vulnerabilities in the WordPress service, please see [WordPress bounty program](https://hackerone.com/wordpress) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* EMM\n* Submissions from former Slack employees within one year of their departure from Slack\n\n# Safe Harbor \nAny activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. \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":"2019-09-10T20:35:30.914Z"},{"id":3604203,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* slackb.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on WordPress, so if you find vulnerabilities in the WordPress service, please see [WordPress bounty program](https://hackerone.com/wordpress) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* Former Slack employees within one year of their departure from Slack\n\n# Safe Harbor \nAny activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. \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":"2019-03-05T09:59:06.157Z"},{"id":3600778,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on WordPress, so if you find vulnerabilities in the WordPress service, please see [WordPress bounty program](https://hackerone.com/wordpress) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* Former Slack employees within one year of their departure from Slack\n\n# Safe Harbor \nAny activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. \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":"2019-01-18T23:21:16.805Z"},{"id":3590888,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on WordPress, so if you find vulnerabilities in the WordPress service, please see [WordPress bounty program](https://hackerone.com/wordpress) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* Former Slack employees within one year of their departure from Slack\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-10-08T16:33:52.595Z"},{"id":3581779,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* Former Slack employees within one year of their departure from Slack\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-06T16:49:37.383Z"},{"id":3581590,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n    * tinyspeck.com\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* CSV Injection\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* Former Slack employees within one year of their departure from Slack\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-05T08:23:59.176Z"},{"id":3579675,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* Former Slack employees within one year of their departure from Slack\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-06-11T18:56:38.240Z"},{"id":3577453,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application. Please note that apps may differ from Slack production, depending on the impact of an issue.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* Former Slack employees within one year of their departure from Slack\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-05-22T18:03:05.865Z"},{"id":3573987,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Open redirect on slack-redir.net\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* Former Slack employees within one year of their departure from Slack\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-04-16T23:22:19.944Z"},{"id":3566378,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* Former Slack employees within one year of their departure from Slack\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-01-08T22:27:57.332Z"},{"id":3566377,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* screenhero.com (We have sunset the screenhero standalone product and as such are no longer accepting reports for that domain)\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* Former Slack employees within one year of their departure from Slack\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-01-08T22:27:02.789Z"},{"id":3564454,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* Former Slack employees within one year of their departure from Slack\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":"2017-12-02T00:50:19.806Z"},{"id":3560165,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* Former Slack employees within one year of their departure from Slack\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":"2017-09-07T23:26:20.712Z"},{"id":3549151,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. We look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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":"2017-03-16T05:52:02.697Z"},{"id":3549141,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of March 2017, we have paid out over $210,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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":"2017-03-16T01:58:39.790Z"},{"id":3544453,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of June 2016, we have paid out over $150,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-0 bugs only for the following:\n    * screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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":"2017-01-09T18:23:05.814Z"},{"id":3544279,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of June 2016, we have paid out over $150,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-3 and Higher: screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n    * IDN homograph attacks\n    * RTL Ambiguity\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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":"2017-01-06T18:41:50.457Z"},{"id":3542939,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of June 2016, we have paid out over $150,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-3 and Higher: screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including:\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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-07T19:48:57.206Z"},{"id":3542938,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of June 2016, we have paid out over $150,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-3 and Higher: screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including\n    * SPF and DKIM issues\n    * Content injection\n    * Hyperlink injection in emails\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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-07T19:48:33.520Z"},{"id":3539992,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of June 2016, we have paid out over $150,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-3 and Higher: screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Brute Force attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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-10-06T23:14:25.713Z"},{"id":3539535,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of June 2016, we have paid out over $150,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-3 and Higher: screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Content Spoofing\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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-09-27T21:03:29.462Z"},{"id":3538950,"new_policy":"**NEW: [Program Update and Guide](https://slack-files.com/T2C8V3QM6-F2C8VAE9L-57d0d1dd01)**\n\nSlack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of June 2016, we have paid out over $150,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-3 and Higher: screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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-09-15T23:32:28.908Z"},{"id":2976881,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of June 2016, we have paid out over $150,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-3 and Higher: screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Issues relating to Password Policy\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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-06-27T21:23:31.996Z"},{"id":2884534,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of June 2016, we have paid out over $150,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-3 and Higher: screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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-06-09T21:44:05.956Z"},{"id":2600942,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of December 2015, we have paid out over $110,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-3 and Higher: screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* \"Scanner output\" or scanner-generated reports\n* Publicly-released bugs in internet software within 3 days of their disclosure\n* \"Advisory\" or \"Informational\" reports that do not include any slack-specific testing or context\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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-05-05T20:15:06.698Z"},{"id":2574631,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of December 2015, we have paid out over $110,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* \"Tab-Nabbing\" or other `rel=\"noopener\"` bugs\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-3 and Higher: screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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-04-29T21:30:15.121Z"},{"id":2514446,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of December 2015, we have paid out over $110,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a HackerOne report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-3 and Higher: screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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-04-18T19:55:05.772Z"},{"id":2514442,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of December 2015, we have paid out over $110,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* **Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.**\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n* **Contacting our support team (feedback@slack.com) about the status of a hackerone report will result in an immediate disqualification for a bounty for that report.**\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-3 and Higher: screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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-04-18T19:54:28.914Z"},{"id":2157789,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of December 2015, we have paid out over $110,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-3 and Higher: screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* **Contacting our support team (feedback@slack.com) about the status of a hackerone report will result in an immediate disqualification for a bounty for that report.**\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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-01-11T16:48:51.116Z"},{"id":2157773,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of December 2015, we have paid out over $110,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* Tier-3 and Higher: screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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-01-11T16:43:21.087Z"},{"id":2135973,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of December 2015, we have paid out over $110,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n* Apps that are maintained by Slack itself (and *not* 3rd party applications).  To identify apps that are in scope for bug bounty, please go to the page for that app (for example, [email](https://slack.com/apps/A0F81496D-email)) and ensure there is no link to \"Report this app\" under the icon for the application.\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Third-party applications on the Slack Application directory (identified by the existence of a \"Report this app\" link on the app's page).  Please report issues with these services to the creator of that specific application.\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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-01-05T18:29:30.767Z"},{"id":2107676,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of December 2015, we have paid out over $110,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* screenhero.com (and subdomains that explicitly are run by Slack, and are required for the screenhero service to operate)\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* 3rd-party subdomains of screenhero.com that are not explicitly required for the product to function (e.g. feedback.screenhero.com is not in scope)\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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":"2015-12-22T18:32:35.748Z"},{"id":2106159,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of December 2015, we have paid out over $110,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* screenhero.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues  (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)\n* CSRF-able actions that do not require authentication (or a session) to exploit\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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":"2015-12-22T06:41:18.055Z"},{"id":2066843,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of December 2015, we have paid out over $110,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* screenhero.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - these sites runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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":"2015-12-04T18:09:21.336Z"},{"id":2064671,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of December 2015, we have paid out over $110,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* screenhero.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Full-Path Disclosure on any property\n* Version number information disclosure\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - this site runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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":"2015-12-03T20:44:58.743Z"},{"id":2064659,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of December 2015, we have paid out over $110,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* screenhero.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Full-Path Disclosure on any property\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - this site runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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":"2015-12-03T20:39:00.617Z"},{"id":2064257,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of December 2015, we have paid out over $110,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* screenhero.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Full-Path Disclosure on slackatwork.com\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - this site runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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":"2015-12-03T18:09:51.782Z"},{"id":2061720,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of December 2015, we have paid out over $110,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we usually pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* screenhero.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - this site runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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":"2015-12-02T18:44:52.084Z"},{"id":2061680,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of December 2015, we have paid out over $110,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* screenhero.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com and blog.screenhero.com - this site runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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":"2015-12-02T18:36:24.225Z"},{"id":2059458,"new_policy":"Slack is committed to treating our customers’ data with the utmost care. As part of this, we encourage security researchers to put our security to the test - and we offer a variety of rewards for doing so. As of December 2015, we have paid out over $110,000 to researchers, and we look forward to continuing to work with the community as we add new features and services.\n\nThis page is intended for security researchers. For general information about security at Slack, please see our [main website](https://slack.com/security).\n\nLove hacking on Slack? [We’re hiring security engineers](http://grnh.se/kr6ptl)!\n\n# Program Rules\n\n* Automated testing is not permitted.\n* Follow HackerOne’s [Disclosure Guidelines](https://hackerone.com/guidelines).\n* Test only with your own team(s) when investigating bugs, and do not interact with other accounts without the consent of their owners.\n* You must be the first person to report the issue to us. We will review duplicate bugs to see if they provide additional information, but otherwise only reward the first reporter.\n* We award bounties at time of fix, and will keep you posted as we work to resolve them.\n\n# Bug Bounty Rewards\n\nThe following guidelines give you an idea of what we pay out for different classes of bugs. Low-quality reports may be rewarded below these tiers, so please make sure that there is enough information for us to be able to reproduce your issue.  Step-by-step instructions including how to reproduce your issue starting out by creating a fresh Slack account are preferred.  Screenshots and videos are also helpful, but please make sure to not make these public before submitting them to follow our program’s rules.  \n\nThere is no maximum reward - particularly creative or severe bugs will be rewarded accordingly.  Depending on the severity of the bug, and the quality of your report, we may pay a lower-tier bug out at a higher level.\n\n## Tier 4: Very Low Severity Bugs     $50 and up\n* Mixed content issues\n* No other types of issues at this level will be considered for bounty\n\n## Tier 3: Low Severity Bugs    $100 and up\n* Self-XSS (XSS requiring interaction other than browsing to exploit)\n* Server misconfiguration or provisioning errors\n* Information leaks or disclosure (excluding customer data)\n* And other low-severity issues\n\n## Tier 2: Medium Severity Bugs     $500 and up\n* XSS that affects other teammates within a team\n* Cross-Site Request Forgery on Sensitive Actions or Functions (CSRF/XSRF)\n* Broken Authentication affecting a single team\n* Privilege Escalation affecting a single team\n* SSRF to an internal service, hosted by slack\n* Information leaks or disclosure (including customer data)\n* And other medium-severity issues\n\n## Tier 1: High Severity Bugs    $1000 and up\n* XSS that affects more than one team (cross-team exploitation)\n\n## Tier 0: Critical Severity Bugs  $1500 and up\n* SQL Injection\n* Remote Code Execution\n* Privilege Escalation affecting all teams\n* Broken Authentication affecting all teams\n* SSRF to an internal service, with extremely critical impact (e.g. immediate and direct security risk)\n* And other critical-severity issues\n\n# What’s In Scope\n\n* slack.com\n* api.slack.com\n* status.slack.com\n* screenhero.com\n* Tier-0 bugs only for the following:\n    * slackatwork.com\n    * slack-redir.net\n    * slack-files.com\n    * slack-imgs.com\n    * spaces.pm\n* Current versions of the official Slack applications for Windows, Mac, Linux, iOS, Android, and Windows Phone\n\n# Testing notes\n\n* CSRF: we use a parameter named `crumb` for our CSRF tokens in our production application.  CSRF reports that include this parameter in the proof of concept will be marked as invalid.\n* Cookie Scope: the only sensitive cookies in the Slack product reside on `.slack.com` and not on other `slack-` domains. \n\n# Exclusions\n\nThe following bugs are unlikely to be eligible for a bounty:\n* Issues found through automated testing\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service attacks\n* Spam or Social Engineering techniques, including SPF and DKIM issues\n* Reports related to the following security-related headers:\n    * Strict Transport Security (HSTS)\n    * XSS mitigation headers (`X-Content-Type` and `X-XSS-Protection`)\n    * X-Content-Type-Options\n    * Content Security Policy (CSP) settings (excluding `nosniff` in an exploitable scenario)\n* Bugs that do not represent any security risk - these should be reported to feedback@slack.com.\n* Issues with other domains or applications owned or related to Glitch or Tiny Speck\n* Security bugs in slackhq.com - this site runs on Tumblr, so if you find vulnerabilities in the Tumblr service, please see [Tumblr’s bounty program](https://www.tumblr.com/docs/en/bug_bounty) for reporting details\n* Security bugs in third-party applications or services built on the Slack API - please report them to the third party that built the application or service\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\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":"2015-12-01T23:13:01.727Z"},{"id":1994863,"new_policy":"This page is intended for security researchers. To find out more about Slack's security, please visit our [security information page](https://slack.com/security). If you believe you have found a security vulnerability on Slack, we encourage you to let us know right away. We will investigate all legitimate reports and do our best to quickly fix the problem.\n\n# ** Automated testing is not permitted **\n\nUsing automated tests will automatically disqualify you from all bug bounties and will result in account termination.\n\n## Responsible Disclosure Policy\n\nIf you give us a reasonable time to respond to your report before making any information public and make a good faith effort to avoid privacy violations, destruction of data and interruption or degradation of our service during your research, we will not bring any lawsuit against you or ask law enforcement to investigate you.\n\nTo show our appreciation for our security researchers, we offer a monetary bounty for certain qualifying security bugs.\n\n## Bug Bounty Rewards\n\n* Our minimum reward is __$100 USD__ for minor issues, while we expect to reward __$500+ USD__ for major vulnerabilities\n* Bugs allowing access to the private information of a user on the same team have a __$500 USD__ minimum reward.\n* Bugs allowing access to the private information of another team or the users of another team have a __$1000 USD__ minimum reward.\n* There is no maximum reward: each bug is awarded a bounty based on its severity and creativity\n\n## Bug Bounty Eligibility\n\nTo qualify for a bounty, you must:\n\n* Adhere to these [Disclosure Guidelines](https://hackerone.com/guidelines) and our Responsible Disclosure Policy (above)\n* Report a bug that could compromise the integrity of Slack user data, circumvent the privacy protections of Slack user data, or enable access to a system within the Slack infrastructure, such as:\n    * Cross-Site Scripting (XSS)\n    * Cross-Site Request Forgery (CSRF/XSRF)\n    * Broken Authentication (including Slack OAuth bugs)\n    * Remote Code Execution\n    * Privilege Escalation\n    * Provisioning Errors\n* Please only test with your own team when investigating bugs. Automated testing is not permitted\n* Do not interact with other accounts without the consent of their owners\n* You must be the first person to report the issue to us. If a duplicate reproduction is submitted while the vulnerability is still in the wild, we will only award a bounty if the duplicate submissions provide more information or show the hole to be more extensive.\n* Find an issue with slack.com, slack-files.com or one of our official applications.\n* Communicate with our security team exclusively via HackerOne.\n\nOur security team will assess each bug to determine if it qualifies.\n\n## Exclusions\n\nThe following bugs are not eligible for a bounty (and we do not recommend testing for these):\n\n* Reports about slack-redir.net being an open redirector, because this domain is intended to be used as a redirector.\n* Security bugs in third-party applications built on the Slack API\n* Security bugs in third-party services that integrate with Slack\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service Vulnerabilities\n* Spam or Social Engineering techniques\n* Issues with other domains or applications owned or operated by Tiny Speck\n* Reports relating to HSTS (Strict-Transport-Security) - we can't enable it yet but plan to\n* Internet Explorer specific headers (`X-Content-Type` and `X-XSS-Protection`). We already set these headers where we feel appropriate.\n* No-immediate risk vulnerabilites such as Full Path Disclosure on any page on slackatwork.com\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":"2015-11-16T16:05:26.159Z"},{"id":1698497,"new_policy":"This page is intended for security researchers. To find out more about Slack's security, please visit our [security information page](https://slack.com/security). If you believe you have found a security vulnerability on Slack, we encourage you to let us know right away. We will investigate all legitimate reports and do our best to quickly fix the problem.\n\n# ** Automated testing is not permitted **\n\nUsing automated tests will automatically disqualify you from all bug bounties and will result in account termination.\n\n## Responsible Disclosure Policy\n\nIf you give us a reasonable time to respond to your report before making any information public and make a good faith effort to avoid privacy violations, destruction of data and interruption or degradation of our service during your research, we will not bring any lawsuit against you or ask law enforcement to investigate you.\n\nTo show our appreciation for our security researchers, we offer a monetary bounty for certain qualifying security bugs.\n\n## Bug Bounty Rewards\n\n* Our minimum reward is __$100 USD__ for minor issues, while we expect to reward __$500+ USD__ for major vulnerabilities\n* Bugs allowing access to the private information of a user on the same team have a __$500 USD__ minimum reward.\n* Bugs allowing access to the private information of another team or the users of another team have a __$1000 USD__ minimum reward.\n* There is no maximum reward: each bug is awarded a bounty based on its severity and creativity\n\n## Bug Bounty Eligibility\n\nTo qualify for a bounty, you must:\n\n* Adhere to these [Disclosure Guidelines](https://hackerone.com/guidelines) and our Responsible Disclosure Policy (above)\n* Report a bug that could compromise the integrity of Slack user data, circumvent the privacy protections of Slack user data, or enable access to a system within the Slack infrastructure, such as:\n    * Cross-Site Scripting (XSS)\n    * Cross-Site Request Forgery (CSRF/XSRF)\n    * Broken Authentication (including Slack OAuth bugs)\n    * Remote Code Execution\n    * Privilege Escalation\n    * Provisioning Errors\n* Please only test with your own team when investigating bugs. Automated testing is not permitted\n* Do not interact with other accounts without the consent of their owners\n* You must be the first person to report the issue to us. If a duplicate reproduction is submitted while the vulnerability is still in the wild, we will only award a bounty if the duplicate submissions provide more information or show the hole to be more extensive.\n* Find an issue with slack.com, slack-files.com or one of our official applications.\n* Communicate with our security team exclusively via HackerOne.\n\nOur security team will assess each bug to determine if it qualifies.\n\n## Exclusions\n\nThe following bugs are not eligible for a bounty (and we do not recommend testing for these):\n\n* Reports about slack-redir.net being an open redirector, because this domain is intended to be used as a redirector.\n* Security bugs in third-party applications built on the Slack API\n* Security bugs in third-party services that integrate with Slack\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service Vulnerabilities\n* Spam or Social Engineering techniques\n* Issues with other domains or applications owned or operated by Tiny Speck\n* Reports relating to HSTS (Strict-Transport-Security) - we can't enable it yet but plan to\n* Internet Explorer specific headers (`X-Content-Type` and `X-XSS-Protection`). We already set these headers where we feel appropriate.\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":"2015-07-24T16:48:10.414Z"},{"id":1670972,"new_policy":"This page is intended for security researchers. To find out more about Slack's security, please visit our [security information page](https://slack.com/security). If you believe you have found a security vulnerability on Slack, we encourage you to let us know right away. We will investigate all legitimate reports and do our best to quickly fix the problem.\n\n# ** Automated testing is not permitted **\n\nUsing automated tests will automatically disqualify you from all bug bounties and will result in account termination.\n\n## Responsible Disclosure Policy\n\nIf you give us a reasonable time to respond to your report before making any information public and make a good faith effort to avoid privacy violations, destruction of data and interruption or degradation of our service during your research, we will not bring any lawsuit against you or ask law enforcement to investigate you.\n\nTo show our appreciation for our security researchers, we offer a monetary bounty for certain qualifying security bugs.\n\n## Bug Bounty Rewards\n\n* Our minimum reward is __$100 USD__ for minor issues, while we expect to reward __$500+ USD__ for major vulnerabilities\n* Bugs allowing access to the private information of a user on the same team have a __$500 USD__ minimum reward.\n* Bugs allowing access to the private information of another team or the users of another team have a __$1000 USD__ minimum reward.\n* There is no maximum reward: each bug is awarded a bounty based on its severity and creativity\n\n## Bug Bounty Eligibility\n\nTo qualify for a bounty, you must:\n\n* Adhere to these [Disclosure Guidelines](https://hackerone.com/guidelines) and our Responsible Disclosure Policy (above)\n* Report a bug that could compromise the integrity of Slack user data, circumvent the privacy protections of Slack user data, or enable access to a system within the Slack infrastructure, such as:\n    * Cross-Site Scripting (XSS)\n    * Cross-Site Request Forgery (CSRF/XSRF)\n    * Broken Authentication (including Slack OAuth bugs)\n    * Remote Code Execution\n    * Privilege Escalation\n    * Provisioning Errors\n* Please only test with your own team when investigating bugs. Automated testing is not permitted\n* Do not interact with other accounts without the consent of their owners\n* You must be the first person to report the issue to us. If a duplicate reproduction is submitted while the vulnerability is still in the wild, we will only award a bounty if the duplicate submissions provide more information or show the hole to be more extensive.\n* Find an issue with slack.com, slack-files.com or one of our official applications.\n* Communicate with our security team exclusively via HackerOne.\n\nOur security team will assess each bug to determine if it qualifies.\n\n## Exclusions\n\nThe following bugs are not eligible for a bounty (and we do not recommend testing for these):\n\n* Security bugs in third-party applications built on the Slack API\n* Security bugs in third-party services that integrate with Slack\n* Security bugs in software related to an acquisition for a period of 90 days following any public announcement\n* Vulnerabilities requiring physical access to the victim's unlocked device\n* Denial of Service Vulnerabilities\n* Spam or Social Engineering techniques\n* Issues with other domains or applications owned or operated by Tiny Speck\n* Reports relating to HSTS (Strict-Transport-Security) - we can't enable it yet but plan to\n* Internet Explorer specific headers (`X-Content-Type` and `X-XSS-Protection`). We already set these headers where we feel appropriate.\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":"2015-07-16T11:54:13.223Z"}]