Skip to main content
Your app’s Trust Center is a security page that Lovable generates for your externally published app. When a customer, reviewer, or investor asks “is this app secure, and how do I check?”, you send this link instead of a screenshot or a promise. It shows facts about how your app is served, secured, and built, checked by Lovable against your live app. You don’t fill in a questionnaire or write any claims yourself: Lovable publishes what it observes, and your app’s code can’t change the results. Every eligible published app gets two addresses on its own domain:
  • 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.
The Trust Center is informational, not a certification. It shows security facts that Lovable observed about your app. It is not an audit, and it doesn’t declare your app “certified secure.” Formal certifications such as SOC 2 or ISO 27001 are separate things that the Trust Center doesn’t replace.
The Trust Center is your app’s outward-facing security page. For related but different surfaces:

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.
The claims can’t be faked, which is what makes the page credible: they are generated and stored only by Lovable’s own services and tied to the exact version of your app that’s live. Your app’s code cannot write, edit, or restyle them, and neither can anyone else’s.

Where to find it

The Trust Center lives on your published app’s own domain, including custom domains: The trust page is as public as your published app. Apps published only to workspace members don’t have a Trust Center. The page is excluded from search engines. It’s meant to be shared by link, not discovered by search.

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.
Deployment and runtime security covers the published version of your app and the components it’s built from:
  • 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.
Access control and authorization covers database protections, for apps that use Lovable Cloud:
  • 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.
Security scanning and remediation covers security tooling that is active for the project:
  • 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.
To see which checks your app shows, open your own trust page and compare it against this list.

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:
1

You publish your app

Publishing externally makes your app eligible. There is nothing to configure.
2

Lovable evaluates the deployment

Lovable visits your live app over the network to run the connection and browser checks, and reads its own platform records, such as the software inventory, for the deployment checks.
3

Lovable publishes the results

The results become claims tied to your project and the exact content of that deployment.
4

Results stay current

Lovable re-evaluates after every publish, and on a regular refresh schedule in between.
5

Visitors see verified claims

Every time the trust page or trust.json is served, Lovable verifies the claims document and refuses to serve anything tampered, stale, or belonging to a different deployment.
A few properties of this design are worth knowing:
  • 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.
The page shows an Evidence evaluated timestamp for when Lovable last evaluated the evidence. If a check is omitted from the page, Lovable makes no claim about its state. An omitted check is not an alert that something is wrong. If a check you expected is missing, review your app in the project Security view, ask Lovable in chat to help address what’s missing, and republish. The Trust Center re-evaluates the new deployment automatically. When you talk about your Trust Center with customers, the same precision protects you: it shows verifiable security hygiene, observed by the platform. It is not a certification, an audit, or a statement that the app is secure.

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.
Treat the expiry timestamps as authoritative: an expired document means the claims are stale, not that the app regressed.

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.json show 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

No. The Trust Center reports facts Lovable observed about your app. It is not an audit and does not certify compliance. It can make a vendor review faster, but a customer who requires a formal certification such as SOC 2 still requires it.
Your app was last published before the Trust Center existed, so there is no evidence for it yet. Republish the app and Lovable evaluates the new deployment and generates the page. This works for older React + Vite projects too, without upgrading your app’s stack.
No, and that’s the point. The page’s credibility comes from the fact that neither you nor your app’s code can alter it. Claims are generated and stored by Lovable and bound to your exact deployment.
The page shows only what Lovable can currently confirm. An omitted check means Lovable makes no claim about it. It is not an alert, and it doesn’t mean your app has been breached or your data exposed. To improve what the page shows, review your app in the project Security view, ask Lovable in chat to help, and republish. The Trust Center re-checks the new deployment automatically.
The Trust Center is for apps published externally with Lovable hosting, regardless of plan. Both newer apps built on TanStack Start and older React + Vite apps get one, and you don’t need to know which one your app is on. It describes the published deployment, so unpublished projects, preview environments, and apps published only to workspace members don’t have one.
A new deployment is evaluated fresh. Lovable re-checks the controls for the new deployment and publishes new claims. Old results are never carried over silently. Expect a short delay after publishing before the Trust Center reflects the new deployment. Between publishes, Lovable also refreshes results on a regular schedule.
trust.lovable.dev covers Lovable as a company: the platform your app runs on. Your app’s Trust Center covers your specific app. The trust page links to Lovable’s platform trust information for the hosting layer.
The Security center is for you: it surfaces issues in your projects so you can fix them, and it’s visible only inside Lovable. The Trust Center is for your customers: it publishes verified facts about your live app on your app’s own domain. The two are independent, and Trust Center checks never create Security center findings.
No. A page Lovable builds inside your app is part of your app’s own code: you own it, you can edit it, and so can anyone who can edit your project. The Trust Center is generated and served by the platform and can’t be edited from your app. Both can coexist. Use the Trust Center when the fact that you can’t edit it is the value.
No. Evaluation runs separately from publishing, never blocks a deployment, and never fails one.