so thank you to bubble support and i am impressed with the detail of the reponse
here it is
How does Bubble manage or provide the following: Detects and prevents web-based attacks in front of public facing web applications, to continually check all traffic?
Bubble is built on Amazon Web Services, which is itself compliant with certifications such as SOC 2, CSA, ISO 27001, and more. We use automated code testing, vulnerability testing (including OWASP Top 10) and continuous monitoring technologies. We use AWS RDS’s AES-256 encryption to encrypt data at rest. All of our Bubble apps are hosted by Cloudflare. Cloudflare also provides security by protecting Internet properties from malicious activity like DDoS attacks, malicious bots, and other nefarious intrusions.
Please describe the internal network protections employed by the system.
- Ensuring that the cloud infrastructure Bubble apps are hosted on is secure at a physical, network, and virtual machine level
- Ensuring that data uploaded to Bubble apps is stored in an encrypted and secure manner
- Protecting against application-level security vulnerabilities in Bubble’s editor and its run-time programming environment
- Ensuring that Bubble’s programming language can be used to build secure applications, and making sure customers are informed on how to use Bubble’s programming language securely
- Ensuring that third party data processors that Bubble chooses to use in order to provide its services operate to the same standards that Bubble does, and ensuring that they process users’ data in a secure and private manner
- Provide and encourage SSL encryption for apps hosted on Bubble
- Store data encrypted at rest in our databases
- Use one-way encryption to protect passwords
- Use firewalls to defend our network from intrusions
- Ensure all servers are fully patched on each deploy, and maintain the capability to patch our entire infrastructure within hours if necessary
- Use secure operating systems (*nix-based) on all Bubble servers
- Use vulnerability monitoring tools to detect potential vulnerabilities in our infrastructure
- Work with security researchers to identify and resolve security vulnerabilities
- Have defined incident management and notification processes for dealing with security incidents
- Review new development work for security implications before releasing to production
- Use Amazon Web Service’s state-of-the-art data centers to ensure good physical security for our data
- Perform background checks on employees with access to customer data
Describe how you have implemented technical measures and applied a defense-in-depth strategy throughout your infrastructure?
For security, our focus is on making the parts of the systems that we have direct control over as robust to hacking as we can. Our goal is that data should only be accessible to the people that the app creator intend that data to be accessible to. So security is a collaborative effort between us and our customers: we see our job as doing our part to make Bubble apps secure, and to give our customers the tools and knowledge to their part. That includes promoting features such as Privacy Rules that give our customers the ability to secure their app.
Bubble’s stance on privacy is that we are in the business of providing a platform and tools to our customers, not in the business of selling user data. The only benefit we try to derive from data stored on our systems by our users is improving those systems and making them more useful for our customers. We don’t sell data to third parties, and we treat data in our care with respect.
We view it as the responsibility of our customers to define the relationship with their own users: we have a wide range of apps on Bubble for all kinds of purposes, so our goal is to enable our customers to pick the privacy practices that make sense for their context.
Bubble’s stance on compliance is that we’re providing a set of tools to our users that can be used in either compliant or non-compliant ways. In general, we will not weigh in on whether a specific use of Bubble is compliant or not, because our customers are all subject to different regulations, and because we do not want to be in the position of giving legal advice.
However, we do want to make it easy for our customers to be compliant. The way we can do this is by documenting our processes and comparing them to practices required by common regulations, and getting external certifications and audits, to make it easy for customers to see if we meet a given regulatory standard. We have invested in helping our customers be GDPR compliant: you can see our terms 15, privacy policy 11, and DPA 18 for more information.
In addition to helping our users be compliant, we do our best to comply with all regulation that we believe that Bubble itself may be subject to. That includes US law governing technology providers, as well as the GDPR.
Please describe how customers/tenants are segmented either logically or physically.
Bubble apps are hosted on Cloudflare. Cloudflare is an edge network provider. In mostly non-technical terms, this means that they run data centers all over the world, close to your users. When a user makes a request, Cloudflare routes the request intelligently to the closest Bubble server or, if it can fulfill the request from a cache (for instance by serving up your static app code and images), it doesn’t even have to send the request to Bubble at all.
Describe your data architecture within your data store for handling shared customer instances and single customer instances that have internal data segmentation requirements.
Privacy rules are the primary tool in Bubble for specifying who ought to be able to see what data. When designing an application, you should think through, for each kind of data your app will store, who ought to be able to see it. Just the user who uploaded the data? The user and certain other users who meet specific conditions? The general public?
If the answer is not “the general public”, then it is important to create privacy rules. Think of each rule you create as a reason someone ought to be able to see a piece of data. For instance, one reason might be, “I’m the user who uploaded it”. Another reason might be “The user who uploaded it tagged me”. More information on how to set up and use privacy rules is in our manual: https://manual.bubble.is/working-with-data/privacy-and-security.html 42
Privacy rules get applied whenever your app searches for or retrieves data. Behind the scenes, we add them as extra constraints to searches: if you search for all users, what we really do is search for “all users who the currently logged-in user is allowed to see”. This applies to searches on a page, as well as searches inside workflows: whenever we are running a workflow, we track who the “current user” is, and only show that workflow data that is allowed by privacy rules.
The general rule of thumb is: if privacy rules allow someone seeing data, that person can see it. Don’t rely on hiding things on a page or redirecting to a different page to protect secure data, and don’t rely on not having built a search anywhere that returns the data. Those measures might stop someone from stumbling on data accidentally, but they won’t stop someone determined to view it.
If you need to modify data that the current user is not allowed to see, the best approach right now is to use a scheduled API workflow with the “Ignore privacy rules when running the workflow” box checked. This will run the workflow entirely on the server without sending data to the user’s web browser, and it will remove the restrictions on searches, so that the workflow can retrieve data that the user wouldn’t otherwise be able to access.
Does your solution or service offer per-tenant memory isolation and protection?
See above response.
Please describe how the data planes and management planes are segmented and controlled.
Bubble is built on Amazon Web Services, which is itself compliant with certifications such as SOC 2, CSA, ISO 27001, and more. We use AWS RDS’s AES-256 encryption to encrypt data at rest. Additionally, all Bubble app’s have Cloudflare’s protection on apps and APIs, please feel free to check out their website for more information.
Please describe how your platforms handle disconnected data interchange, or secure practices for external data interchange.
We use AWS RDS’s AES-256 encryption to encrypt data at rest. See firsthand the encryption we use for data in transit.
Please describe your remediation cadence for security patching, bug fixing, and new releases cadence.
Your Bubble apps can access point-in-time data recovery for your own data at any time. Your Bubble apps come with logs so that you can review what your app has done, even in the background. We certainly understand how important reliability is on Bubble, and this is currently one of our highest priorities alongside performance. Additionally, our Bubble Status page is updated on any platform-wide issues to keep our users informed. On this status page, you can subscribe to updates via email, SMS, Slack, Twitter, etc. We also have an incident history on our status page to review all past incidents as well. We post monthly announcements in our Bubble Forum to keep our community updated. One of our Co-CEOs will also post a community update monthly in our accouncements.
Please describe your malicious code/end point protections employed within the system.
Bubble is built on Amazon Web Services, which is itself compliant with certifications such as SOC 2, CSA, ISO 27001, and more. We use automated code testing, vulnerability testing (including OWASP Top 10) and continuous monitoring technologies. We use AWS RDS’s AES-256 encryption to encrypt data at rest. All of our Bubble apps are hosted by Cloudflare. Cloudflare also provides security by protecting Internet properties from malicious activity like DDoS attacks, malicious bots, and other nefarious intrusions.
Please describe how you ensure firmware/software integrity prior to implementation (checksums, code signing, etc).
We use automated code testing, vulnerability testing (including OWASP Top 10) and continuous monitoring technologies.
