Is This Website Legit? How to Vet an App Built With AI

You landed on a site, maybe from an ad, a link a friend sent, or a search result, and before typing in an email or a card number, one question is running through your head: is this website legit? That's a reasonable instinct. Fake stores and phishing pages cost people real money every year, and most are easy to spot once you know the signals.

There's a second version of the same question, though, and it's the one this post is really about. It comes up when the site or app in question is yours, usually one built fast with an AI tool like Lovable, Bolt, or Base44. That question isn't "will this take my money." It's "will this leak my users' data, even though the business behind it is completely real."

Those are two different tests, and a site can pass one while failing the other. Here's the checklist for judging any third-party site first, since that's useful on its own. Then the part most "is it legit" checklists miss.

⚡ TL;DR

• A legit business has findable contact details, a real terms of service and privacy policy, a domain and certificate that match, and reviews you can verify off the site itself.
• Legit and secure are not the same test. A real, funded company can still ship an app with a wide-open door in it, because none of the legitimacy signals check for that.
• Base44's July 2025 incident is the proof: a well-funded platform, patched by Wix in under 24 hours, and still a bug that let a stranger create a verified account inside any private app.
• If the site in question is your own app, being legit is the floor, not the ceiling. The next question is whether it protects the data you're already collecting.

Is this website legit? Start with these signals

Before anything technical, check the basics that separate a real business from a scam.

• Contact details that work. A real support email, ideally a phone number or address matching the business. Try it first; a bounce or dead form is a red flag.
• A real terms of service and privacy policy. Not boilerplate with the wrong company name still in it. It has to exist and describe what happens to your data.
• A domain and certificate that match. The site should load over HTTPS. Click the padlock to see who the certificate was issued to; it should match the business name. A new domain paired with "trusted by thousands" claims is a common scam pattern.
• Reviews you can verify elsewhere. On-site testimonials are easy to fake. Look on independent review platforms or social media. No footprint outside the site itself is a warning sign.
• No lookalike URL, no pressure tactics. Watch for extra words, swapped letters, or an unfamiliar domain ending standing in for a brand you recognize, plus countdown timers or gift-card-only checkouts.

If a site fails several of these, treat it as untrustworthy no matter how polished the design looks. Design is cheap to fake; a paper trail is not.

A legit company can still ship an insecure app

Here's where the two questions split apart.

Everything above tests identity: is this a real business, run by real people, that won't disappear with your money. That's the right question for a stranger's checkout page. It's the wrong question for an app that will store your account, your messages, or your customer data long after the first transaction.

Security is a separate test: once the business checks out, can its app protect what it collects? An AI page builder like Lovable, Bolt, or Base44 lets a small team, often non-developers, ship a full app in days instead of months. That speed helps legitimacy signals: fast founders, weekly releases, a product that works. But the AI writing that code optimizes for "does this feature work in the preview," not "is access to this data locked down." Those are different jobs, and the second doesn't show up in a demo. More on the pattern in our full rundown on whether apps built with AI tools are secure.

The result is a category of company that is entirely legit by every test above, and still has a gap that legitimacy checks were never built to catch.

The Base44 example: legit, funded, still had a hole

Base44 is a real product, backed by Wix, with a real user base. It passes the checklist: a real company, a real support channel, real terms. By the standard "is this website legit" test, there's nothing to flag.

In July 2025, Wiz Research found what the checklist couldn't see. A public app_id, combined with undocumented register and verify-OTP (one-time password) endpoints, let anyone create a verified account inside any private app on the platform, bypassing single sign-on (SSO) entirely. Roughly 20,000 users were on affected apps. Wix patched it in under 24 hours, with no evidence it was exploited before the fix.

Nothing about Base44's business was fake. The company was funded and fast to fix the problem. What failed was an authentication flow, which has nothing to do with whether the storefront looks trustworthy. See the full Base44 security writeup for details, and the vibe-coding breach timeline for how this fits a broader pattern across AI-built platforms. The same shape of problem, a real company with a gap only visible once someone probes the login or the database, recurs across the platforms covered in our complete guide to vibe-coding security.

How to check your own site or app right now

If you shipped the app, here's what a "legit or not" scan will never surface.

1. Test it as a stranger. Open your app in a private browser window with no account logged in. Load pages and API routes that should require login. If data comes back, that's a real problem.
2. Look for secret keys in your frontend code. Search your loaded JavaScript for service_role, sk_live, or any raw provider API key. None of those belong in code the browser can read. A Supabase anon key or Firebase web config is expected and fine; those are meant to be public.
3. Check your response headers.

curl -I https://yourapp.example.com

Look for Content-Security-Policy, Strict-Transport-Security, and X-Content-Type-Options. Missing headers won't sink you alone, but their absence is a decent proxy for a deploy that never got hardened after the demo worked.

4. Confirm database rules actually restrict access, not that a toggle is switched on. On Supabase, read the policy text, since Row Level Security (RLS = a per-row filter the database applies to every query) can show "enabled" and still pass every row. Our Lovable security checklist walks through reading those policies even if you're on a different platform, since the underlying backend is often the same.
5. Try to reach files you didn't mean to expose, like /.env, /.git, or a stray config.json, directly in a browser tab.

Being legit is the floor, not the ceiling

One more thing worth clearing up, since it trips people up in both directions.

A public Supabase anon key or Firebase web config visible in your app's source is not a leak. Both are designed to live in the browser by default. Plenty of scanners flag them as critical anyway, training founders to panic over the wrong thing and ignore the real one: a secret key, like a Stripe sk_live_ key, a Supabase service_role key, or a raw provider API key, sitting in code the browser can read. Same for a database table with no real access rule behind it.

A legitimacy check answers "will this business scam me." A security check answers "can this app protect what it already collected from me." You need both, and passing the first tells you nothing about the second. An attacker can find the second kind of gap in minutes by reading your app's network traffic. The defense is finding it first, and checking again after every deploy, since an AI-assisted codebase changes constantly.

FAQ

How can I tell if a website is a scam versus insecure?

A scam site is built to take your money with no intention of delivering anything real: fake contact details, no verifiable reviews, pressure to act now. An insecure site can be a real business with a technical gap, like missing access controls on its database. The first is a fraud question the checklist above covers. The second requires testing the app, not reading its "About" page.

Does HTTPS mean a website is safe?

HTTPS means your connection is encrypted in transit. It says nothing about what happens to your data once it reaches the server, or whether that database is locked down. Plenty of sites with a valid certificate still have wide-open backends.

Can a well-funded, legitimate company still get hacked?

Yes. Base44 is a documented example: a real, backed company, patched within a day of disclosure, with no evidence the flaw was exploited first. Funding affects how fast a company responds; it doesn't prevent the problem, especially in apps built quickly with tools that prioritize working features over locked-down defaults.

What's the fastest way to check if my own app has this kind of gap?

Run through the five checks above; most take a few minutes each. A read-only scan of your live URL can automate the same checks and surface exposed keys, missing headers, and access-control gaps without reading a line of code.

The bottom line

"Is this website legit" and "is this app secure" are different questions, and treating them as one is how a real, funded company still ends up in a breach report. Use the checklist above to judge whether a business is who it says it is. If the app is yours, passing that test is the starting line, not the finish. The gaps that cause real damage, missing RLS, exposed secret keys, open storage buckets, don't care how legitimate your company is. They only care whether anyone checked.