Responsible Disclosure Program

Platform.sh is a Platform-as-a-Service where customers can host their applications and make them available to the world without worrying about the "how". We take the security of our systems seriously, and we value the security community. The responsible disclosure of security vulnerabilities helps us ensure the security and privacy of our users and of everyone that uses their services.

Program Guidelines

This is a responsible disclosure program, we are not offering bounties, monetary or otherwise, at the moment. Actionable reports may be rewarded on a discretionary, case-by-case basis.

We require that all reporters:

• Make every effort to avoid privacy violations, degradation of user experience, disruption to production systems, and destruction of data during security testing. Only interact with accounts you own or with the explicit permission of the account holder.
• Do not disrupt our normal operations by testing vulnerabilities related to rate limiting, with the only exception being any attack amplification issues.
• Use the established communication channels to report findings.
• Keep information about any vulnerabilities you’ve discovered confidential between yourself and Platform.sh until we’ve had 90 days to resolve the issue.
• Coordinate with us if intending to disclose publicly after resolution.

If you follow these guidelines when reporting an issue to us, we commit to:

• Not pursue or support any legal action related to your research (aka "Safe Harbor").
• Provide feedback on your report.
• Work with you to validate and resolve the issue (including an initial confirmation within 72 hours of submission).

Program Scope

Platform.sh operates as a PaaS where customers can host their applications and leverage our tooling to enhance their productivity.

In order to make this process simpler, Platform.sh provides customers with algorithmically generated subdomains to access their projects under our platform.sh and platformsh.site domains. According to our shared responsibility model, customers are responsible for the security of their applications so customer applications will always be out of scope for the purpose of this program.

How to tell if it’s a customer application or a Platform.sh owned one?

• It uses our colors and logos.
• It provides PaaS services (e.g., not an eCommerce shop).
• It’s linked in the main Platform.sh site.
• The subdomain is just one level below platform.sh or platformsh.site (e.g., https://*.platform.sh).

If none of these apply, it is most likely to be a customer website hosted through our service and therefore out of scope. We recommend that you check thoroughly before submitting as the majority of our reports concern customers’ assets which we will not process.

Our scope also includes Blackfire, our APM observability tool that employs a software agent and offers rich metrics dashboards through their website. Blackfire is integrated into Platform.sh, but can also be acquired and used as a stand-alone product. We will consider reports from both usage modes but the same rules apply: we only care about the Blackfire agent and dashboards, not the applications that are being monitored.

In addition to customer applications, any 3rd party providers and services are also excluded. For example, Platform.sh offers a chatbot functionality that is wholly provided by a 3rd party, of which we (Platform.sh) are a customer. That is considered out of scope for the purpose of our program, but you are free to reach out to the provider. We do ask that you refrain from using our instances to perform your research as it might degrade service quality, triggering user complaints and conflicting with established scopes.

These 3rd party services include, but are not limited to:

• Drift (talk.platform.sh)
• Stripe
• Slack
• Zendesk
• Disqus
• Google Tag Manager
• fonts.googleapis.com
• cdn.jsdelivr.net

In the interest of the safety of our users, staff, the Internet at large, and you as a security researcher/reporter, the following findings/methods are excluded:

• Findings from physical testing such as office access (e.g., open doors, tailgating)
• Findings derived primarily from social engineering (e.g., phishing, vishing, smishing)
• UI/UX bugs and typographical errors
• Network-level Denial of Service (DoS/DDoS) vulnerabilities
• Spamming of any kind (emails, Zendesk tickets, messages, emails, etc.)

Submit a report

You can reach us by email via our security.txt.

Pre-submission Checklist

We take care in validating every report and we ask you to please do your due diligence and check if the asset is within our scope before submitting a report.

We operate as a PaaS and host a myriad of customer content. Pages under our control (and in scope) will be under *.platform.sh and *.platformsh.site where * matches a single level (TLD style).

E.g.,

eu.platformsh.site - operated by us, in scope

foo.eu.platformsh.site - customer application, not in scope

We also ask for a small description of the vulnerability and its applicability. If you submit a report from an automated tool that simply states that a version is different than the expected version number (see more examples below), we will always require a PoC or a write-up showing how to leverage that flaw to compromise security properties.

This applies to, but is not limited to:

• Clickjacking/X-Frame-Options (see Google's advice on the matter)
• Lack of an/several HTTP header(s) (see above as well)
• SPF, DMARC, DKIM and other email delivery records (those are deliberate)
• TLS/SSH cipher suite offerings (compatibility reasons)
• Customer’s applications
• Outdated application/library versions without a PoC

We do not consider these findings to be valid or actionable and we will never pay a bounty for them, whether monetary or otherwise.

When submitting a report please use the following structure:

• Summary: short description of what the vulnerability is.
• Steps to reproduce: how to replicate it for validation and/or a working PoC
• Impact: what is the viable impact of this vulnerability and how could that be leveraged to compromise security properties.

You can add any additional reference materials to support the report, but we will gauge it on the quality of the write-up itself.

If your report concerns accessible and/or exposed data, please do not include samples in your report to "boost its strength" . We ask that you provide us with the necessary information to validate the findings as including them in the report may trigger regulatory requirements and void "Safe Harbor" provisions. It is in our shared interest that that does not occur.

By data we mean:

• Personally identifiable information (PII)
• Personal health records (PHR)
• Credit cardholder data
• Sensitive customer information (e.g., not source code)

We welcome all responsible researchers and thank you for helping to make Platform.sh more secure.