Security report
https://meu-app.lovable.app
14 findings• full report
This score covers the public surface — what a visitor reaches without logging in. It does not include the logged-in area, what runs on the server, nor other subdomains (api., staging., admin.). The full scope is further down.
- 24
- pages visited
- 1,010
- checks run
- 14
- findings
Work transparency
What we combed through
A real sweep, in a real browser: 24 pages opened and 1,010 checks run.
Pages visited (24)
- https://meu-app.lovable.app/
- https://meu-app.lovable.app/login
- https://meu-app.lovable.app/cadastro
- https://meu-app.lovable.app/painel
- https://meu-app.lovable.app/conta
- https://meu-app.lovable.app/checkout
- https://meu-app.lovable.app/precos
- https://meu-app.lovable.app/sobre
- https://meu-app.lovable.app/contato
- https://meu-app.lovable.app/blog
- https://meu-app.lovable.app/blog/post-1
- https://meu-app.lovable.app/blog/post-2
- https://meu-app.lovable.app/termos
- https://meu-app.lovable.app/privacidade
- https://meu-app.lovable.app/faq
- https://meu-app.lovable.app/recuperar-senha
- https://meu-app.lovable.app/status
- https://meu-app.lovable.app/api/health
- https://meu-app.lovable.app/sitemap.xml
- https://meu-app.lovable.app/robots.txt
- https://api.meu-app.lovable.app/
- https://staging.meu-app.lovable.app/
- https://meu-app.lovable.app/assets/index.js
- https://meu-app.lovable.app/assets/vendor.js
Checks by category
- Exposed secrets2 flaws320
- HTTP headers1 flaw170
- Sensitive files2 flaws120
- Browser storage2 flaws90
- Database1 flaw70
- DNS / email2 flaws60
- Frontend libraries2 flaws50
- API endpoints1 flaw40
- Cookies1 flaw40
- CORS (cross-origin)Clean20
- Transport / TLSClean18
- Resilience (CDN/WAF)Clean12
We don’t guess: every finding shows how sure we are.
- Confirmed(12)seen directly, with proof (the data, file or response itself)
- Likely(2)strong signal, but no direct proof
- To confirm(0)a hint — worth checking before you act
Exposed Supabase service_role key
Your database master key sits in the code any visitor downloads. With it, a stranger reads, edits, and deletes everything — bypassing every access rule you set.
Sensitive data (like the login token) is stored in the browser in a way another script can read — and steal the access.
Exposed secret: Stripe
The Stripe secret key was left in the site. It can issue refunds, pull up your customer list, and touch your payments account — all in your name.
A password or access key ended up visible in the site’s code. Anyone who opens the page finds it — and can use your account, spend in your name, or read your data.
.env file exposed
The .env file is open to the public. It holds every password and key at once — the treasure map served on a platter.
A file that should be private (config, backup) is open on the internet. It’s like leaving the key under the mat, in plain sight.
Firebase database open
Your Firebase database answers with no login. Anyone reads your users’ data, and if writing is open too, edits it — no password, no barrier.
The database can be accessed directly, without the permission rules. In practice, anyone can read (or change) every user’s data.
Session cookie without HttpOnly
The cookie that keeps a user logged in can be read by a script on the page. That alone lets an attacker sign in as them.
The cookie that appears to keep users logged in can be read by JavaScript on the page. If a malicious script ever got onto the site (XSS), it could copy that cookie and use the session. The HttpOnly flag closes that door.
Personal data in the browser
Your customers’ personal data — card numbers, IDs — is kept in the browser, within reach of any script. It’s a leak and a privacy fine waiting to happen.
Your site keeps personal data (like card or ID numbers, or user records) in the browser’s storage (localStorage). Any script on the page can read it, and it stays on the computer — including shared ones.
Public storage bucket
A file bucket (S3/Storage) is listable. Documents, uploads, and backups that should be private can be listed and downloaded one by one.
A file that should be private (config, backup) is open on the internet. It’s like leaving the key under the mat, in plain sight.
Exposed secret: OpenAI
Your OpenAI key leaked in the site. Whoever finds it spends on your quota; the bill, at month’s end, is yours.
A password or access key ended up visible in the site’s code. Anyone who opens the page finds it — and can use your account, spend in your name, or read your data.
Content-Security-Policy missing
With no CSP, an injected script runs free on your page — stealing your users’ data and sessions with no warning.
There’s no rule (CSP) telling the browser where your site may load scripts from. It doesn’t prevent a bug by itself, but it greatly limits the damage if someone manages to inject code into the page.
GraphQL introspection open
The full map of your API — every field and operation — is public. It hands an attacker the blueprint before they even try.
A site endpoint is open or accepting dangerous actions. It can be used to extract data or abuse the system.
Library with a known flaw
Your site loads a library with a public, already-patched flaw. It’s an old unlocked door — bots know exactly how to walk in.
A library the site uses has a known public flaw. It’s a door attackers already know to look for.
DMARC missing
With no DMARC, anyone can email posing as your domain. Your customer falls for the scam, and the lost trust is yours.
Your domain doesn’t tell email providers (Gmail, Outlook…) what to do with messages pretending to come from you (DMARC). Without it, a fake email in your name is more likely to reach your customers’ inbox.
Forgotten subdomains found
We found subdomains you left online (api., staging.). Each is one more door — and the forgotten ones tend to be the weakest.
This is an inventory, not a flaw: addresses under your domain (like api. or staging.) show up in public certificate logs. Worth checking whether any of them is an old or test environment left online — those tend to go unpatched.
Scripts without integrity check
Third-party scripts load with no integrity check. If the provider is compromised, malicious code walks straight into your site.
Your site loads scripts from other companies (like a CDN) without a "fingerprint" that confirms the file wasn’t swapped. If that provider were ever compromised, the altered code would run on your site. Extra protection against a rare but real risk.
Action plan
In this order, not another.
0→100
score after everything · ~6 h 45
the score has a ceiling; the risk slice does not
1Fix today — it’s what opens the door
~4 h 10−93% of the risk- .env file exposed20 min
- Exposed secret: Stripe30 min
- Exposed Supabase service_role key35 min
- Firebase database open45 min
- Session cookie without HttpOnly15 min
- Exposed secret: OpenAI25 min
- Public storage bucket40 min
- Personal data in the browser40 min
2This week — close the gaps
~1 h 45−5% of the risk- DMARC missing15 min
- GraphQL introspection open20 min
- Library with a known flaw30 min
- Content-Security-Policy missing40 min
3When you can — hygiene and reputation
~50 min−1% of the risk- Scripts without integrity check20 min
- Forgotten subdomains found30 min
Order-of-magnitude estimates, for a dev who knows the project. The risk slice and the score projection use the same weight table as the scan — so the number here is what the retest will show.
Scope of this analysis
What was looked at — and, just as clearly, what wasn’t.
In
- The public pages the browser reached from the address you gave
- Every file the site serves to the browser — bundles, scripts, config
- Response headers, session cookies, CORS policy, and TLS configuration
- The domain’s email DNS records (SPF and DMARC)
- Frontend libraries with a known public flaw
- Sensitive files at known paths (.env, .git, backups)
Out
- Everything that only exists after login — we don’t authenticate on your site
- The code that runs on the server: SQL injection, business logic, cross-user permissions
- Server-side dependencies — from outside we only see what the browser downloads
- Infrastructure off the site: database ports, buckets, panels on other subdomains
- Whatever you publish after this scan — the surface changes on every deploy
- The active database test, which requires domain verification
No scan makes a system secure — this one closes the doors that are open to anyone arriving from outside, with no password and no technical knowledge, which is where most incidents in new apps actually happen. The surface changes with every deploy: a scan is a snapshot, not insurance.
Compliance (indicative)Which standards these findings touch
The findings in this report map to controls in the following frameworks:
Indicative mapping to guide remediation — it is not a compliance assessment or certification, and doesn’t replace an audit.
OWASP and CWE classifications are public technical references. The LGPD/GDPR seal is indicative — it flags findings that may leave personal data within third parties’ reach and does not replace legal review.