Well this is a fun one. Iām excited to announce the release of NQU Secure - the most advanced security audit platform in the Bubble ecosystem. And itās completely free.
But hang on, didnāt Bubble just acquire Flusk? Yeah, but I felt that more could be done to vet app security, and thereās a need for third party security review in the ecosystem as a whole.
This is not a micro-tool - it produces deeper, more insightful analysis than any existing Bubble security tools.
The most powerful audit engine ā Context-aware analysis that understands your appās purpose, detailed explanations, and exportable reports
Advanced privacy testing ā Test data access between user types, not just for logged-out users.
Infinite editor version control ā Unlimited version backups with automated scheduling. Free, on all Bubble plans.
Complete data backup solution ā 6 months retention of database, logs, and file manager backups (generously powered by PlanB Backups by @lindsay_knowcode).
Fast and easy to understand - NQU Secure runs fast, and has a simple, clean UI that makes it easy for you to run audits on different apps.
Itās free. No credit card. No premium tier. (We havenāt even integrated a payment gateway!)
Happy building!
FAQ
How is NQU Secure free?
NQU Secure is created and maintained by Not Quite Unicorns agency. The free security platform allows us to demonstrate our expertise while giving back to the Bubble community. Revenue from our agency services funds the platformās development and maintenance.
Will it be free forever? I donāt know - it depends on how expensive it gets. But Iāll do everything I can to keep it free.
Do I need to provide collaborator access?
No! NQU Secure can perform comprehensive security audits without requiring editor or collaborator access.
Can I audit any app?
No! To view the full audit results, youāll need to verify your ownership of the app. This can be done in several ways:
Inviting NQU Secure as a collaborator
Adding a test page
Adding an HTML header
This verification requirement exists because NQU Secureās advanced capabilities need to be used responsibly by legitimate app owners and developers.
How is my data handled?
All app data is stored within Bubble
We use LLMs for certain security checks, but your data is never used for training
Security checks are performed on our self-hosted servers
yah - I am first I was always a fan of Flusk, but I am more of a fan of NQUSecure - It should come with a warning - you will find new vulnerabilities that will disrupt your planned day as you scurry to fix them.
Being able to test with real Users logged is vital - for privilege escalation exploits.
all of the waitlist testers who braved the early bugs!
And, if youāre getting FOMO, thereāll be more bugs so you can help me help the community by reporting them too False positives are more common than false negatives by design, but if you encounter anything you think shouldnāt be classed as an issue, then do use the flag feature to let ue know so we can improve it.
Oh, Iāll be doing an AMA on the Codeless Love Slack tomorrow (Wednesday) if anyone wants to drop by and chat about building maintainable, scaleable, and secure apps on Bubble! Link: Slack
Just want to add - zero affiliation to @georgecollier, but this is genuinely one of the coolest Bubble apps that Iāve seen to date. From onboarding experience, to the dashboard UI, through to the ease of use, this is a brilliant tool and Iād highly recommend to all.
You all are going to bankrupt me with the amount of WU notifications Iām getting If any of you want to share screenshots of example results so people can see what to expect then Iām sure itād be appreciated!
The careful handling applied to the results given.
And that itās free to use.
This is one of, if not the best, contributions that I have seen to the Bubble community. If you have a platform in production, you must must must scan it with this tool.
Side note, we cannot believe that API Connector initialisation response data is publicly available.
One of the things Iām pushing for Bubble to do - automatically sanitise the response sample values.
In case anyone reading didnāt know, when you initialise an API call, the response data is saved to your app code which the user can see. In actuality, Bubbleās engine only needs the type data (is this field a number/boolean/text etc), but it saves the entire sample value. If, then, you initialise an API call and the API returns customer data, thatās now in your app code.
Amazing work @georgecollier ! When is Bubble going to hire you??
I ran my app - at first I was scared that the report said it was leaking API keys, but it just turned out to be test Stripe user accounts. Though it does leave me wondering why Bubble leaves so much of that API connector info open
Awesome job on this. Very few people know about the API responses not being sanitized, hopefully this awareness leads Bubble to make changes around how these responses are displayed. We should be able to make the field names private too, ideally. There is one more very esoteric exploit that Iām going to DM you to include that I donāt believe is checked by you.
Can we do a full-delete of all audited data? Meaning thereās zero trace it was ever ran?
Also, itās good that youāre hiding the details behind a verification wall as otherwise this would be legally very dubious, but can we as verified app owners also submit a request to prevent checks from running? Right now any competitor or investor can collect a non-trivial information about an app. This could present with serious legal consequences down the line, which would be not a good thing for the community as I believe this app is a net good.
You can delete your account or just an appās data (though that has Bubbleās normal deletion limit where I could technically restore the DB for 30 days).
I hadnāt thought about checking it but can add it today probably. Iām going to be adding more of Bubbleās quirky exploits that nobody checks for. Iāll probably need a filter on the audit review page that allows you to filter issues by obscurity so that you can prioritise the easy/obvious issues, and then work on the ones that are still absolutely issues but more complex for an attacker to take advantage of (though not ādifficultā).
How do you mean?
Currently, you can scan an app on the homepage. This will return a summary (number of issues by severity). However, this will be blocked if the app is already verified by someone in NQU Secure. So, if youāve added and verified ownership of your app, nobody else will be able to view the audit summary for that.
And of course, I had the back and forth in my mind of whether even a summary was okay, but I felt that without it people wouldnāt be bothered to even try it as they assume their apps are secure and the ultimate goal should be to get as many people to view their full audit as possible as thatāll lead to the greatest good.
And net good really is the priority. @lindsay_knowcode is generously providing database/log/file backup with PlanB for free for NQU Secure uses. However, that requires Data API access. So, before using it, we require users to run an audit and get passes for every privacy rule check, because we donāt want people with bad privacy rules enabling their data API just for backups!
Itās a real and serious risk. Unless a company has given you permission for this you could land in serious legal trouble. Especially when youāre labeling issues as ācriticalā etc. Even the summary itself is problematic.
Legal issues notwithstanding, it would theoretically be a perfect tool for hackers to increase the yield of attacks by looking at the summary view before diving in.
I donāt think the increased growth from having a short time to value is worth the long-term risk of the instant summary view, both for your tool/agency as well as your relationship to Bubble.
Thanks for flagging. I had to change the model we use for any AI enhanced checks because it was costing hundreds a day as more people were using it than I expected so Iām still dialling this in, but we do more false positives than false negatives. This will only improve in future as I adjust the classification logic and models become more powerful for cheaper. Obviously thereās a future option to lock some high powered/extra accurate models behind a paywall that funds it (on a large app, an audit can cost about $1.50 in AI and WU with GPT-4o/Claude 3.5 Sonnet) but Iād like to avoid that if possible.
Not quite, for a few reasons:
the security density (or vulnerability density) of an application is measured by the number of issues per unit of code size. Therefore, a large application with X critical issues may actually have a better security density than a smaller application with the same number of issues, since the issues are spread across a larger codebase. So, the number of issues alone isnāt particularly interesting
itās dead easy to scan for some of the issues we check, including:
editor access permissions
password policy
leaking API keys
thatās because all of the above are all in the app object thatās present on any Bubble appās page. Itās trivial to load the page, return the object, and do a tiny bit of automated analysis to fix that.
if an app has lots of āmajorā issues, thereās no hint as to where those are coming from. Chances are if it has plenty of major / critical issues, it has a ton of exploitable backend workflows that an attacker can find anyway, perhaps some leaky data API endpoints, etc. So, given itās so easy to exploit already, better the owner can actually realise that.
Donāt forget that Bubbleās own tool, Flusk, runs their privacy checker on any app in the same way, and that returns real (though partially redacted) user data. I think what Iāve added is probably much less risky
Oh, and I hate to break it to you, but your site is already being analysed by hundreds of bots, crawlers, and AIs
Nothing about your tool is trivial, or it wouldnāt have taken months to build it. You are representing a legal entity, not an anonymous Chinese scraping bot network. The core of your arguments is āother people are doing it too.ā Wonāt hold up in court. Feel free to disregard my advice at your own peril, Iām giving it to you for your own good, it doesnāt affect me personally either way.
I did have an auto-fix built out for this (a one-click fix that fixes it in your editor automatically by cleaning all sample values). However, I didnāt release it widely as while developing it I managed to brick my test app to the extent that not even the editor would load to restore from a backup. I had to fix it by unbricking it directly via writing to the App JSON. Powerful yes, fragile, also yes, and I donāt want people using it on production apps!
False positives are more common than false negatives by design, but if you encounter anything you think shouldnāt be classed as an issue, then do use the flag feature to let ue know so we can improve it.
