- A page for people at
/.well-known/trust.html. This is what you share with customers, reviewers, and investors. - A file for software at
/.well-known/trust.json. Automated tools and AI agents read this to check your app without a human involved. You never need to open it yourself.
Why use the Trust Center
Before the Trust Center, showing your app’s security posture meant screenshots, written promises, or a hand-filled spreadsheet. Now you send a link:- Answer “is your app secure?” with evidence instead of reassurance. The page shows what Lovable actually observed about your live app.
- Answer a security-conscious customer’s vendor review with a link instead of a questionnaire.
- Give investors and due-diligence reviewers a live, credible security signal without hiring a security team.
- Show that the security facts come from the platform your app runs on, not from your own marketing copy.
- Show that Lovable keeps a complete inventory of the components your app is built from and monitors them for known vulnerabilities.
- Let procurement tools and AI agents assess your app automatically through
trust.json.
Where to find it
The Trust Center lives on your published app’s own domain, including custom domains:What the Trust Center shows
Security checks
The trust page groups checks into sections, written in plain language so anyone can read them. Your app’s page shows the checks Lovable can currently confirm, so different apps show different sets: an app that uses Lovable Cloud also shows database checks, and an app with security tooling turned on shows that too. If a check is omitted, Lovable makes no claim about its state. A section appears only when at least one of its checks is confirmed, so your page can have fewer sections than listed here. This is the full set of checks Lovable can show today. Connection and browser security covers how your app establishes secure connections and instructs browsers to handle its content:- Insecure links are redirected to HTTPS. If someone opens the app using an insecure HTTP link, they are automatically sent to the encrypted HTTPS version.
- Browsers stay on HTTPS after a secure visit. After someone visits securely, their browser is told to keep using HTTPS when they come back.
- The app’s HTTPS certificate is valid. The app’s web address has a valid certificate, so browsers can connect over HTTPS without a certificate warning.
- Browsers are told not to guess file types. The app tells browsers not to guess a resource’s file type from its contents.
- Other sites are restricted from embedding this app. Other websites are restricted from displaying this app inside their own pages, which helps reduce misleading overlays and clicks.
- The browser gets rules for what this page may load. The app provides browser rules for where scripts and other content may load from.
- The browser gets rules for sensitive features. The app tells browsers which features, such as the camera, microphone, or location, may be used.
- Outgoing links share limited page information. When someone follows a link away from the app, less information about the page they came from is shared.
- Secure cookie settings were observed. Cookies Lovable checked use secure connections and limit cross-site use. Session cookies also block access from page scripts.
- The first page checked avoided insecure resource links. On the first page Lovable checked, scripts, styles, frames, and other active resources were not loaded over insecure HTTP.
- Dependencies were checked for known vulnerabilities. Lovable checked the software packages identified in this deployment against OSV, a public database of known vulnerabilities.
- The latest dependency check found no known vulnerabilities. In the latest complete check, Lovable did not find a known vulnerability in the software packages included in this deployment.
- A software inventory was created for this version. Lovable created an SBOM, which is an inventory of the software packages included in this published version.
- The software inventory matches the version that is published. The software inventory was created for the version of the app that is currently published.
- These facts are tied to the version that is published. These observations are tied to the exact version of the app that is currently published.
- Health checks are turned on. Lovable regularly checks whether the published app is responding.
- A database access review completed for this version. A supported review of the app’s database access rules completed for this published version.
- Record-level database protections are turned on. Every database table Lovable checked has row-level security turned on. This enables access rules for individual records.
- Automatic security fixes are turned on. The project has turned on Lovable’s automated security-fix feature.
- Aikido assessment results were synced. Lovable received results from a connected Aikido security assessment for this published version.
Software bill of materials
Modern apps, including Lovable apps, are assembled from ready-made open source components called dependencies. A software bill of materials (SBOM) is the complete list of those components, in a standard format (CycloneDX) that security tools can read. Lovable creates an SBOM when you publish, as long as it can identify your app’s dependencies. It uses the SBOM for the software inventory and dependency checks above. If your trust page doesn’t show those checks, republish your app to generate a fresh inventory.trust.json discloses that an SBOM exists for the current deployment. The list itself is not publicly downloadable.
How it works
You never set the Trust Center up. It follows your app’s publishing lifecycle:You publish your app
Lovable evaluates the deployment
Lovable publishes the results
Results stay current
Visitors see verified claims
trust.json is served, Lovable verifies the claims document and refuses to serve anything tampered, stale, or belonging to a different deployment.- Claims can’t be faked. Only Lovable services write claims. Your app’s code can’t edit the trust page’s results or restyle it, and your app’s CSS doesn’t apply to it. The page always renders in Lovable’s neutral design.
- Claims are bound to a deployment. Each claim names your project and the exact deployment it was checked against. When you publish a new version, Lovable evaluates the new deployment fresh. Results from an old deployment are never quietly relabeled as current.
- Evaluation never affects your app. Trust Center checks run after publishing, on their own. They never block or fail a deployment, and they don’t create findings in the Security center.
Reading the results
The trust page shows current positive facts: checks that passed and records Lovable holds. Each fact carries a badge that says where it comes from:- Checked means Lovable ran that check against your live app or its deployment and it passed.
- Recorded by Lovable means the fact comes from Lovable’s own platform records, such as which version of your app is live.
- Enabled means a security capability is turned on for your project, such as health checks or automatic security fixes. These mirror Lovable features you manage yourself, in the same project or workspace settings where you normally turn them on or off.
Using the machine-readable claims
You never need to open/.well-known/trust.json yourself. It exists so that software can check your app the same way people read the trust page.
For the technical readers and tools that do consume it: the file returns the same evidence as the trust page in a structured JSON document. Only checks that currently pass are included. Each entry has a stable identifier, whether the fact was probed on the live app or recorded from Lovable’s platform records, and evaluation and expiry timestamps. The document also carries verification metadata that states it is platform-generated and unsigned.
Typical consumers:
- A procurement or vendor-management tool that checks suppliers’ security posture automatically.
- An AI agent doing an automated vendor review before connecting to your app.
- Your own monitoring, if you want to alert when a control changes.
Limitations
- Informational, not certification. The Trust Center is not SOC 2, ISO 27001, a penetration test report, or a compliance attestation, and it doesn’t substitute for any of them.
- Coverage is focused. The checks cover how your app is served (encryption and browser protections), the components it’s built from, and where the deployment came from. The Trust Center is not a full security assessment of your app’s own code and logic.
- Claims are served by Lovable, not cryptographically signed. A reviewer trusts the document because Lovable serves it from your app’s domain. Independently verifiable signed attestations are not part of the Trust Center today.
- Only current positive facts appear. The page and
trust.jsonshow the checks that pass right now. A reviewer can’t tell from the Trust Center alone whether an omitted check failed or was never evaluated.
FAQ
Is this a compliance certification like SOC 2 or ISO 27001?
Is this a compliance certification like SOC 2 or ISO 27001?
My trust page says Republish required. What does that mean?
My trust page says Republish required. What does that mean?
Can I edit the trust page or add my own claims?
Can I edit the trust page or add my own claims?
Why is a check missing from my app's trust page?
Why is a check missing from my app's trust page?
Does every published app get a Trust Center?
Does every published app get a Trust Center?
What happens when I republish my app?
What happens when I republish my app?
How is this different from trust.lovable.dev?
How is this different from trust.lovable.dev?
How is this different from the Security center?
How is this different from the Security center?
I asked Lovable to build a trust or security page in my app. Is that the same thing?
I asked Lovable to build a trust or security page in my app. Is that the same thing?
Does the Trust Center slow down or risk breaking my deployments?
Does the Trust Center slow down or risk breaking my deployments?