Thanks. Just installed it and ran the outcomes in GPT.
One commonly cited example of issues is the use of @latest in popular packages (Lottie you mentioned is indeed a well-known case). If I understand it correctly, the typical risk scenario looks like this:
A maintainer (or a compromised account) publishes a new version of a widely used package that includes malicious code. Any application that pulls @latest immediately starts executing that code. The issue is eventually discovered and patched, but during that window the malicious version is already running in production across many apps. Even if the “good” version is restored quickly, the damage window has already existed.
I understand from my LLM buddy that in teams nromally mitigate this by pinning versions, adding SRI(?), enforcing strict CSP rules, and continuously monitor dependency advisories. In Bubble, however, developers often cannot see, control, or override how a plugin author references these external packages.
The opposite problem also exists a lot: outdated pinned dependencies.
For example, I installed a simple “create PDF” plugin that hasn’t been updated in over two years. The plugin pins this version:
https://cdn.jsdelivr.net/npm/jspdf@1.5.3/dist/jspdf.min.js
That version has known issues acording to ChatGPT. Snyk reports XSS and ReDoS vulnerabilities and recommends upgrading to jsPDF 2.3.1+. The Bubble app developer has no practical way to upgrade or remediate this, because the dependency is buried inside the plugin and the plugin itself is no longer maintained. Menas you could fork the plugin and build something new but this creates a difficult situation:
-
Bubble encourages extensibility through plugins (which is great).
-
At the same time, responsibility for security risks is effectively pushed to end users.
-
Those users often cannot inspect, update, monitor, or even see the third-party dependencies they are now responsible for.
From a no-code / low-code trust perspective, this feels misaligned. I think that many users explicitly choose the Bubble platform to avoid managing low-level dependency security, supply-chain risks, and vulnerability monitoring (on top of numerous other advantages but we’re focussing on security).
I fully understand the complexity here and that this may simply be a blind spot rather than an intentional design choice. That said, it’s easy to imagine these exact scenarios being the root cause of a future high-impact security incident, with serious ramifications for both app builders and the Bubble ecosystem as a whole.
At minimum, some form of visibility or monitoring tooling around plugin-embedded dependencies (versions, update status, known advisories) would go a long way toward addressing this gap.
Chat als came up with the following:
Below is Step 1 expressed cleanly as a formal threat model mapping, keeping it high-level and suitable for security, risk, or executive audiences.
Step 1 — Threat model mapping (STRIDE + CIA)
Primary risk
Uncontrolled third-party JavaScript execution via Bubble plugins
This risk arises when external JavaScript dependencies are embedded through plugins that:
Are opaque to the app owner
May be dynamically versioned (@latest) or outdated
Are not monitored for security advisories
Execute with full client-side privileges
STRIDE mapping
S — Spoofing
Malicious scripts can impersonate trusted client-side components
Fake UI elements, forms, or authentication flows can be injected
Users may unknowingly submit credentials or sensitive data
CIA impact: Confidentiality, Integrity
T — Tampering
Client-side logic can be altered at runtime
Form values, API requests, or workflow triggers can be modified before submission
Business rules enforced in the browser can be bypassed or manipulated
CIA impact: Integrity
R — Repudiation
Malicious code can manipulate analytics, logs, or telemetry
User actions may be misrepresented or obscured
Forensic reconstruction becomes unreliable
CIA impact: Integrity, Availability (operational trust)
I — Information Disclosure
DOM scraping, token theft, and data exfiltration are trivial once script execution is compromised
PII, session identifiers, API keys, and user-generated content can be silently leaked
Exfiltration can occur without visible user impact
CIA impact: Confidentiality (primary), Integrity (secondary)
D — Denial of Service
Malicious or buggy dependencies can crash the UI or block rendering
External CDN outages or dependency removals can break core functionality
Emergency takedowns during supply-chain incidents can cause widespread outages
CIA impact: Availability
E — Elevation of Privilege
Compromised scripts inherit the full trust of the application’s client-side context
Attacker-controlled code can execute privileged actions intended only for trusted logic
Combined with backend misconfigurations, this can enable broader compromise
CIA impact: Confidentiality, Integrity
CIA summary (executive view)
CIA Pillar
Impact Level
Rationale
Confidentiality
High
Silent data exfiltration and token theft are trivial once JS is compromised
Integrity
High
Business logic and user actions can be manipulated without detection
Availability
Medium
Outages are likely during incidents or CDN failures but are not the primary goal
Not sure what to make of this.
.