Sooner or later, someone has to decide whether they think your app is secure. Either a customer deciding whether to give you their data, an investor running diligence before a fundraise, or a client's IT team deciding whether it's safe to roll out for employees.
Until now, your answer was your word. You filled in a questionnaire, wrote a reassuring email, and promised the basics were handled. The person on the other side had no direct way to check.
Today we’re introducing trust centers for every business published on Lovable: a dedicated security page, at your app's own address, showing which security controls are live. Lovable reads them straight from your app and shows what it finds. Nothing for you to fill in.
What is a trust center?
If you've never sold software to a company, you may never have run into one.
When a business wants to adopt a piece of software, someone has to check that it's safe before they commit. This is a security review, and it happens in almost every B2B deal. The reviewer wants to know things like: is data encrypted in transit, who are the third parties involved, how are known vulnerabilities handled etc.
Established software companies got tired of answering those questions one email at a time, so they started publishing a single page that answers them up front. That page is a trust center and it usually lays out:
- Data protection: whether data is encrypted in transit and at rest, and how it's stored
- Access and authentication: how logins are secured, who can get to what
- Subprocessors: the third-party services the product relies on, like hosting or payments
- Compliance: audits and certifications the company holds, such as SOC 2 or ISO 27001
- Vulnerability handling: how security issues get reported, tracked, and fixed
Having a trust center usually meant having a security team. You needed people to gather the evidence, a budget for an audit like SOC 2, and someone to keep the page current. A two-person company shipping a product had no way to show it took security seriously, even when it did.
Now, building on Lovable gives you the advantage of having this out of the box. The controls a security reviewer asks about come standard with our platform, without you having to hire a security team, run an audit, or maintain a page.
This is not a certification
Even for an enterprise, having a trust page is informational, it is not a certification. It is a page that shows your certifications and observed controls. It does not mean your business is automatically secure or compliant, and the page will not claim otherwise. But it is valuable because until now, there was no way to visibly prove that what you’ve built on Lovable was safe out-of-the-box.
It gives you a visible way to prove what you’ve built on Lovable is secure at the platform level. But we want your feedback! Tell us whether this helps your customers, investors, or you get a clearer picture of your app’s security.
How to use it
Any app you publish to public (not just a workspace) will expose a trust center. To see it, go to: YOURAPPURL/.well-known/trust.html. Here is an example: https://parisian-scribe-app.lovable.app/.well-known/trust.html
Note: your app's code cannot write, edit, or restyle anything on the trust page, it is automatically created by Lovable. This will currently only work for newly published projects, legacy projects will be able to create trust centers shortly.
What's on the page
Finally, here is a full list of what you can see on the page:
Connection and browser information
- HTTPS enforcement: visitors using an insecure HTTP connection are automatically sent to HTTPS, so the app loads over an encrypted connection.
- Strict transport security (HSTS): tells browsers that have already visited the app to keep using HTTPS for future connections.
- Valid TLS certificate: confirms that the app’s hostname presents a trusted, unexpired certificate, allowing browsers to establish an encrypted connection without a certificate warning.
- Protection against MIME sniffing: tells browsers to respect each resource’s declared file type instead of guessing whether it should be handled as executable content.
- Protection against clickjacking: restricts other websites from embedding the app inside their own pages and placing misleading controls over it.
- Content Security Policy: declares browser rules describing which code and content the app is allowed to load.
- Referrer policy: limits how much information about the current page is shared when someone follows a link to another website.
- Browser permissions policy: declares how browser capabilities such as the camera, microphone, and location may be used by the app.
- Secure cookie protections: cookies observed in the evaluated response use encrypted transport and same-site protections. Observed session cookies are also protected from access by browser scripts.
- Protection against insecure page resources: the initial page avoids directly loading the inspected scripts, frames, stylesheets, and other active resources over insecure HTTP.
Dependencies and deployment information
- Dependency vulnerability checking: Lovable checks the current deployment’s identified dependencies against OSV, Google’s public database of known open-source software vulnerabilities.
- No known dependency vulnerabilities detected: when a complete OSV check returns no matches, the trust center reports that no known vulnerabilities were detected in the evaluated dependency inventory.
- Software bill of materials: a machine-readable CycloneDX inventory records the software components included in the evaluated deployment.
- Current dependency inventory: confirms that the software inventory matches the app’s current published revision rather than an earlier deployment.
- Deployment traceability: links the trust center’s observations to the exact published revision, content hash, and deployment time they describe.
- Health monitoring: scheduled Lovable health checks monitor the published app’s availability.
Access control and authorization
- Database authorization review: records when a supported database authorization review has completed for the current published revision.
- Database row protection: identifies when every observed table in the database’s public schema has row-level security enabled.
Security scanning and remediation
- Automated security fixes: shows when a project has enabled Lovable’s automated security-remediation capability.
- Connected Aikido assessment: shows when findings from a connected Aikido assessment have been synchronized for the current published revision.
Coming soon: more information about your backend services, data residency, AI gateway controls, list of subprocessors.
