Trust center

Your app’s Trust center is a security page with checks verified by Lovable for your externally published app. It combines live checks with Lovable’s platform records to show confirmed security properties of your current deployment. Share it with customers, reviewers, and investors as evidence for security reviews, without writing or maintaining the results yourself. When the Trust center is enabled for a project, its 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.

​

Why use the Trust center

Instead of maintaining screenshots or writing security claims yourself, share a page that Lovable updates as your app changes:

• Answer questions about your app’s security with checks verified by Lovable using live evidence and platform records.
• Support vendor reviews with a link to current security evidence, alongside any questionnaires or certifications a customer requires.
• Give investors and due-diligence reviewers evidence-backed security information that Lovable generates and maintains.
• Show that the security facts come from the platform your app runs on, not from your own marketing copy.
• Share results of software inventory and known-vulnerability checks for the dependencies Lovable identified in the current deployment.
• Let procurement tools and AI agents assess your app automatically through trust.json.

Lovable generates, validates, and serves these results, and ties them to the exact version and domain of your app that’s live. Your app’s code cannot write, edit, or restyle the platform-served results.

​

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.

​

Enable or disable the Trust center

The Trust center is disabled by default. To publish the trust page for your app, enable Trust center in Project settings → Publishing. Project admins and owners can change the setting.

• Enabling it applies to your app’s current published version: Lovable evaluates the live deployment and publishes the trust page within a few minutes, no republish needed. If the project isn’t published yet, the page appears after your first external publish. For apps last published before the Trust center existed, the trust page shows Republish required until you publish once more.
• Disabling it takes both /.well-known/trust.html and /.well-known/trust.json offline within about a minute. You can enable it again at any time, and Lovable re-evaluates your current published version.

​

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 an inventory of identified software 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

Once you enable the Trust center, it follows your app’s publishing lifecycle: A few properties of this design are worth knowing:

• Lovable verifies and serves the results. Lovable evaluates live checks and platform records before publishing results. Your app’s code can’t edit the platform-served results or restyle the page, and your app’s CSS doesn’t apply to it. The page renders in Lovable’s neutral design.
• Claims are bound to a deployment. The results are tied to the exact app version and domain that Lovable evaluated. 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, describe it as specific security checks verified by Lovable for the current deployment. It is not a certification, an audit, or a guarantee 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 results 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 identifies the results as platform-generated. 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.
• 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