Verified purchaser
Until Sept 24, 2026, ANY registered NoCodeBackend user — free or paid — who knew your email address could view YOUR databases and copy YOUR master API keys. I reported it privately; they silently patched it, then replied "We don't see any issues."
Until Sept 24, 2026, ANY registered NoCodeBackend user — free or paid — who knew your email address could view YOUR databases and copy YOUR master API keys. I reported it privately; they silently patched it, then replied "We don't see any issues."
Plain language, for non-technical buyers: type someone's email into one page of the app, and it handed back that person's master keys — live API keys with full read/write authority, plus internal database credentials. No hacking, no password guessing. Your data was only as safe as your email address being unknown. The one check that stops this — "is the asker actually the owner?" — is a single line of code. It was missing — and with no monitoring, a less honest visitor could have pulled other customers' data for months without the vendor ever knowing. I reported it instead. Whether anyone exploited it first is something no one — including the company — can rule out.
The other half of this review is what the vendor did with a free, reproducible security report from a customer. I paid for the top tier nine months ago but, beyond an initial test setup, had barely used it — Sept 24 was my first real attempt to build with it, and the problems surfaced that same day. Until then I had no complaints; this would have been 4 stars. Here is the sequence.
What I found (Sept 24, 2026)
Three findings, reproduced against my own paid account only:
Broken access control (IDOR). GET /api/databases/list scoped its response to an email query parameter and never checked that the caller's token belonged to that email. Any registered account plus any customer's email returned that customer's full database list — including live sk_live keys with full CRUD authority and internal DB credentials.
Database port open to the entire internet. The production DB host (129.146.189.183) had port 3306 (MariaDB 10.6.7) world-reachable. Shodan had indexed it months earlier. Every customer's data lives on this single shared instance — one set of leaked credentials exposes all tenants.
No rate limiting on authenticated endpoints, and everything runs on a single VM with no replica — one host failure takes down every customer at once.
What I did — with the exact timeline
On Sept 25 I sent a private disclosure report — endpoints, reproduction steps, evidence, fixes. Timeline (UTC):
09:36 — I send the full disclosure report to support.
09:45 (+9 min) — Simar replies: "Let our security team go over it and we will respond you back soon."
11:07 — With no reply on the substance since the 9-minute acknowledgment, I request a refund for my top-tier purchase, citing the security state.
11:10 (+3 min) — Simar replies: "We don't see a any issues for the critical vulnerabilities you reported. The architecture works as expected. Secondly, unfortunately no refund can be granted after nearly 9 months of usage. Kindly go through our refund policy."
The security team was supposedly "going over it" — yet "no issues" landed 3 minutes after my refund request, too fast for any investigation, while the fix was already live: acknowledge, patch, deny, refuse refund.
What actually happened to the "non-existent" issues
My Sept 25 re-tests found:
/api/databases/list now returns 403 Forbidden — server-side ownership validation added. The exact fix my report recommended.
Port 3306 no longer accepts connections (timeout), while 443 on the same host responds normally — a selective firewall rule, not an outage.
Real enough to patch immediately; not real enough to acknowledge.
Anyone can verify this independently
Shodan's free InternetDB still holds the record for 129.146.189.183 — port 3306 open, MariaDB 10.6.7 — captured by a third party before my report. Check it yourself at internetdb.shodan.io. If port 3306 "worked as expected," there would have been nothing to close.
Why this matters more than the bugs
Silently shipping a fix is normal, and patching fast is competent engineering. But replying "we don't see any issues" in writing, minutes after acting on my report, is a choice: fix the code, deny the problem, keep the review score.
And the quiet part: I chose to report — someone who chose to steal needed only a list of email addresses, and the company would never have known. That uncertainty is the real product of this architecture, and their answer to it was "works as expected."
If they had replied "thank you, you're right, we've patched it," this would have been a 5-star review. They chose the other path.
Buyer's note: the product idea is good and the AI database setup genuinely saves time. If you keep anything sensitive here, know what was behind it: a missing one-line ownership check, a database port open to the whole internet (Shodan-verified), a single shared server with no replica — and a support reply that calls all of that "as expected."
Evidence preserved: before/after captures, timestamps, disclosure correspondence. Facts limited to my account and third-party (Shodan) records.