Here’s something useful to know about the API Connector that isn’t widely talked about, and isn’t particularly intuitive: when you set up an API call, the initial response gets saved in your app’s code. This means if your test response contains any sensitive data, it becomes part of your app’s client-side code.
So, what content in your API Connector is public?
Anything not marked as private, is public.
Assume that anything not in a parameter marked as private is public. Sounds obvious, doesn’t it? The screenshot below shows which data is public in this API call. Red is publicly visible, and green is private.
URLs
body structure
any sample values in parameters that aren’t private
This is the one that gets people. When you initialise the API call, the entire response is stored in the app code.
I (and NQU Secure) have found admin API keys, highly personal customer data and more lying around in apps that weren’t aware of this vulnerability.
How It Works
When configuring the API Connector:
You make a test API call to set up the response structure
Bubble saves this response in your app code
This saved response becomes accessible as part of your app’s static content
What To Consider
If your test API response includes:
Customer information
API keys or tokens
Internal configuration details
These will be stored in your app’s code. While this isn’t always a problem, it’s smart to use sanitised or test data.
Solution
The fix is straightforward - just ensure your test response doesn’t contain sensitive information while maintaining the same structure. This means:
Using placeholder data in your test response by changing any response values to ‘example’ or ‘null’.
Keeping the response structure identical
Saving this clean version as your default response (use ‘Manually enter API response’.
Fixing it quickly
To make this process easier, I’ve also created a free tool (no signup required) on NQU Secure that automatically sanitizes API responses while preserving their structure. You can try it out on the homepage without any account - use to your heart’s content.
Yes. If you’re initialising a new API call, you’ve got to save it, then re-click Manually enter API response rather than just ‘edit raw data’. That’ll make sure type info is preserved.
And yes, I’ve built a feature that automates this in one click for all API calls, but I bricked my app while building it and don’t want to risk doing that to yours hence it’s not released
“move fast and break stuff”…has served some billionaires well in silicon valley, for me personally moving too quickly has always cost me 2-3 times as much time if I had just gone a bit slower, as the time it took to break something, figure out why, then redo without breaking.
Yeah, well I’m taking the slow approach here haha.
By brick my app, I mean brick it so that not even the editor loads and I can’t restore from a savepoint. I had to unbrick it by reverse engineering how I bricked it
That’s actually why I built the backup feature. Before we make any change to your app (we support some basic config auto-fixes) we take a backup. And then I was like, well, might as well put the little bit of effort in to let you backup whenever you want, on a schedule.
If you can think of any other micro-tools that would help with your security or building in general then do let me know and I’ll build them.
Thanks for this latest security tip. It’s a very valuable series.
Indeed, this was the most revelatory issue when I first ran NQU Secure earlier this week. It’s really helpful that you’re surfacing these unknown unknowns. Ideally, such issues wouldn’t be overlooked in Bubble’s implementation in the first place; however, given that they’re present and can be worked around, they should have been noted in the manual long ago (here’s another opportunity for improvement, @petter).
Just leaving this here - I added bulk API call sanitisation to NQU Secure. You can easily sanitise your entire API Connector in a few seconds rather than going through it all manually.
