Security White Paper

October 2025
Scope: This white paper explains the security implications and practices for custom applications built with Lovable.dev and ProptechOS. It covers how these applications handle data and identity, the controls in place to protect customer information, and the shared responsibilities between our development team and your IT organization.

Introduction

Applications built on Lovable.dev and integrated with ProptechOS, Microsoft Entra ID (Azure Active Directory), and Supabase achieve a a robust security posture by architecture and combined practices. These solutions combine browser-based execution (no secrets stored in the app), granular role based authorization for for data in ProptechOS, with data protection backed by enterprise-grade security in Azure AD, Lovable, and Supabase — all three SOC 2, ISO 27001, and even HIPAA-compliant platforms.

Because Lovable apps for ProptechOS execute entirely in the user’s browser, they contain no embedded secrets or confidential data. All authentication, authorization, and data storage occur through secure, audited services — each enforcing strong encryption, token-based access, and tenant isolation. Azure AD governs identity and MFA; Supabase handles encrypted data storage and row-level access control; and ProptechOS ensures governed, policy-driven real-estate data management.

The result is a security model that aligns with industry best practices and regulatory expectations. When implemented with the outlined configurations and operational safeguards in this paper, the combined architecture represents best-practice security for modern property-technology applications — minimizing risk exposure, protecting customer data, and maintaining full transparency and control for enterprise IT teams.

Architecture & Data Flow

System Overview: A Lovable-based application typically consists of a web front-end (built and hosted via Lovable.dev) that interacts with:

• The ProptechOS Platform (Backend) – our core real estate data platform. It provides a unified API for building data. 
• Supabase (Database & Auth) – a cloud Postgres database used by the app for specific aggregated data and operational data (e.g. caching or app-specific records). 
• Azure Active Directory (Microsoft Entra ID) – the identity provider for authenticating users. Users log in with their Azure AD credentials, and tokens from Azure AD secure the connections to both the app and the ProptechOS API. 

Data Flow Steps:

1. User Authentication: When a user accesses the Lovable application, they are prompted to log in with their ProptechOS account, via Azure AD. The app redirects the user to Azure AD’s secure sign-in page. After successful authentication (with MFA if enabled on your tenant), Azure AD issues an OpenID Connect ID token (proving the user’s identity) and an OAuth2 access token for authorized API calls. These tokens are specific to our registered app and your tenant, meaning only your organization’s users can log in. 
2. Session Establishment via Supabase: The Lovable front-end uses Supabase’s integration to handle the authentication response. Supabase verifies the Azure AD token (ensuring signature and audience are correct) and creates a user session for the app. Through Supabase’s Auth, the user gains a JWT (JSON Web Token) for the database with their unique user ID and any relevant role info. This JWT is used by the front-end for subsequent database requests. Supabase acts as a bridge – it allows Azure AD to be used as an auth provider for the app, so we don’t store passwords or manage users separately. 
3. Data Retrieval from ProptechOS: When the now-authenticated user interacts with the app (say viewing sensor readings or updating an asset record), the app needs data from ProptechOS. The front-end will call ProptechOS APIs – these are secured endpoints that accept Azure AD access tokens. The user’s Azure AD access token (obtained at login) contains the necessary scopes/permissions that ProptechOS recognizes. The request goes from the browser to ProptechOS’s cloud endpoint over HTTPS. ProptechOS validates the Azure AD token (checking issuer, audience, scopes, and that the user is authorized for the specific data). Upon validation, ProptechOS returns the requested data (e.g., real-time IoT readings, asset info) to the app. This approach means the app never stores Proptech data itself; it’s fetched on demand with the user’s permission.
   

4. Data Storage & Sync in Supabase: Some apps also use Supabase’s Postgres database as a data warehouse or cache. For example, ProptechOS might push certain aggregated data (like monthly energy usage or floor maps) into the Supabase DB to improve front-end performance or enable offline queries. Supabase then holds this subset of data (fully within our control and for your organization only). Any query the Lovable app makes to Supabase includes the user’s JWT, so Supabase knows who is requesting the data. Row-Level Security policies (explained later) ensure the user can only access rows they’re allowed to. The Supabase DB is also used for any app-specific data not in ProptechOS (for instance, user preferences or annotations) – all tied to your tenant. Data flows from ProptechOS to Supabase through secure backend processes or APIs we’ve set up (often via scheduled jobs or webhooks). 
5. App Display and Interaction: The Lovable front-end (which runs in the user’s browser) combines data from ProptechOS APIs and Supabase queries to present a unified interface. For instance, a dashboard might show live sensor stats from ProptechOS (via API) alongside historical trends stored in Supabase. All of this occurs without exposing any direct database connections or secrets to the user; the app uses either the user’s Azure AD token or the Supabase user token to mediate every request. 
6. User Actions: If the user performs an action (e.g., toggling a device, approving a tenant request), the app sends the appropriate command via a secure API call. For ProptechOS actions, this would again go through a ProptechOS API endpoint (authorized by Azure AD token and ProptechOS API role). For actions that involve Supabase data (e.g., inserting a comment in a log table), the app calls Supabase’s RESTful endpoint or RPC function, which in turn will only execute if the user’s JWT and RLS policy allow it. 

Logging and Monitoring: Throughout this flow, various logs are generated. Azure AD records an entry for the user login (and any token issuance). ProptechOS logs the API call (including which user accessed which resource). Supabase logs any database query made (with user context). Our system aggregates key events from these logs for monitoring (described later in Monitoring & Logging).

Architecture Diagram

Isolation and Deployment: Each Lovable application is deployed in a containerized environment in Lovable’s cloud platform or our managed hosting. Applications do not share databases or runtime instances. Customer data is strictly partitioned by application instance. There is no multi-tenant data store at the app level – if we build an app for Company A and another for Company B, their data resides in completely separate Supabase databases and ProptechOS tenant contexts. This greatly reduces the risk of any accidental data crossover. ProptechOS itself is designed as an operating system for real estate portfolios with tenant isolation (each customer’s building data is segregated, and apps interface through standard APIs). Supabase projects are similarly isolated and each requires distinct keys. In summary, the architecture ensures that each customer’s app data and access are self-contained.

Next, we detail the security principles that guided the design of this architecture, followed by the concrete security controls at each layer.

Security Principles

Our security strategy is built on four core principles:

• Security by Design: From the outset, we incorporate security into the application design rather than as an afterthought. The architecture leverages proven security services (Azure AD, encrypted databases, etc.) and defaults to secure configurations. For example, all user access is mediated by centralized identity, and all network communication is encrypted. By designing with security in mind, we reduce the chance of vulnerabilities in the deployed apps and ensure compliance with common standards (the Lovable platform itself is SOC 2 Type 2 and ISO 27001 certified, reflecting a strong security baseline (lovable.devlovable.dev). 
• Least Privilege: Every component and user in the system has only the minimum access required to perform its function. API calls are scoped to the smallest necessary privilege, and internal service credentials (like database keys) are limited in capability. For instance, the front-end uses a Supabase anon key that cannot modify the database, and all write operations requiring higher privileges are funneled through secure backend functions. Likewise, tokens issued to the app carry only the roles/claims needed (and we avoid broad admin tokens in the client). Limiting privileges in this way confines potential damage – even if a component is compromised, its permissions are so constrained that it cannot breach other parts of the system. 
• Zero Trust Architecture: We adopt a “trust nothing, verify everything” stance, especially at integration boundaries. Each request – whether coming from the front-end, from an API, or even from inside our platform – is authenticated and authorized as if coming from an untrusted network. Azure AD tokens are validated on every ProptechOS API call; Supabase requires a valid JWT on each query, and further enforces row-level policies. No component inherently trusts another based on network location or past interactions. Even within the app, if one module requests data from another, it must prove its privileges. This zero trust approach ensures that a breach in one area (say, the front-end code) cannot automatically cascade into unauthorized data access without passing the necessary security checks at each step. 
• Data Isolation & Transparency: Customer data is logically and physically isolated. Each app has its own database schema or instance, and access controls tying data to its rightful owner. We maintain clear segregation between customers – there is no commingling of data. It also means that within a multi-user app for your company, one user’s actions or data cannot accidentally expose another’s data unless explicitly intended by business logic (such as an admin viewing a team member’s entries – and even then, only through controlled interfaces).

These principles guide every security control and practice described next. They ensure that our approach is holistic – covering not just technical mechanisms but also aligning with your organizational policies and expectations (like least privilege access for your staff and clear data ownership boundaries).

Security Controls

In this section, we detail the concrete security controls implemented across various aspects of the Lovable-based application stack. These controls map to the architecture described above and collectively enforce the security principles. We’ll cover: authentication and identity management, API security and data validation, encryption practices, deployment and hosting security, secrets management, and monitoring/logging. Each subsection outlines how the control is implemented and why it’s important for maintaining a secure environment.

Authentication and Identity

Centralized Identity with Azure AD: All user authentication is handled by Microsoft Entra ID (Azure AD), meaning users log in using corporate credentials that you already manage. We do not create separate app passwords or accounts. This approach ensures that your existing identity policies extend to the app. For example, if an employee leaves your company and you disable their Azure AD account, they automatically lose access to all Lovable-based apps. Azure AD integration also allows us to honor multi-factor authentication (MFA) and any conditional access policies you have in place. If you require MFA for login (which we recommend and typically enforce for all admin-level users), the user must satisfy that to get into the app – there is no bypass. By leveraging Azure AD, we essentially inherit enterprise-grade identity security including passwordless options, risk-based sign-in detection, account lockouts, and integration with your directory governance. In short, the app’s user access is as secure as your Azure AD tenant.

Single Sign-On (SSO): The applications are registered as enterprise applications in Azure AD, which means users might also access them via your internal portal or by selection in the Office 365 app launcher if configured. This SSO capability provides a seamless and secure user experience – users don’t juggle new passwords and benefit from the single sign-on trust established with your directory. It also eases user provisioning; you can assign Azure AD groups or users to the application to control who has access, and only those users will be able to authenticate. This model shifts the access control decisions to you (the customer’s IT team), giving you full control over who can use the app through your familiar Azure AD interface.

OAuth2 Authorization for APIs: When a user logs in, Azure AD issues tokens that the app uses to call backend APIs. Specifically, we use OAuth2 authorization grants to get an access token for the ProptechOS API. This token is scoped to specific permissions (for example, read access to building telemetry, or write access to certain resources, depending on the user’s role). ProptechOS validates this token on each request, ensuring the user is allowed to perform the action in question. We register distinct App IDs for different applications or client types (web vs. mobile if needed) to maintain granular control. No API call is accepted without a valid token – if a token is expired or tampered with, it’s rejected and the user must log in again. Additionally, the tokens are short-lived and we utilize refresh tokens securely via Supabase to maintain sessions without constant logins. This token-based approach aligns with modern zero-trust practices (every request is authenticated) and ensures there is no “backdoor” or shared admin password used in API communications.

Role-Based Access Control (RBAC): Both the ProptechOS platform and our Supabase backend implement RBAC to differentiate between user roles. For instance, within ProptechOS, a user might be assigned a role that only allows viewing data for certain buildings or performing certain tasks. Azure AD groups or role claims are used to convey these roles. We configure the application to receive these roles in the token (using Azure AD’s group/role claims functionality – which can even include the groups a user is in). The Lovable front-end and Supabase will interpret these roles to, for example, display admin features only to admins or restrict certain API calls. On the database side, roles can be mapped to Row-Level Security conditions (e.g., a user with role “PropertyManager” can see data for their property only). This layered RBAC means that even once authenticated, users have fine-grained access aligned with their job function. Everything is need-to-know. If down the line you need a new role (say, a “Regional Manager” who can see multiple sites), we can introduce that via Azure AD and update the policies accordingly. The key point is, identity isn’t one-size-fits-all; it carries attributes that we use to enforce least privilege access within the app’s context.

Protection Against Unauthorized Access: We have measures to ensure only legitimate users from your organization access the apps. As noted, we set the Azure AD application to single-tenant mode, meaning only accounts from your Azure AD (or guests you explicitly add to your tenant) can authenticate. We also configure the Azure AD app with an allow-list of redirect URLs and ensure that tokens are audience-restricted to our app, preventing tokens from being re-used elsewhere maliciously (supabase.com). Supabase, which manages the auth flow on the app side, is configured with the Azure AD tenant ID – any token not from that tenant is rejected. Additionally, we include an optional claim in Azure AD tokens to indicate if the user’s email is verified by your domain, mitigating a known issue where unverified emails could be used to spoof identities. In summary, only authorized tenant users with verified credentials can get into the system. Should someone attempt to use, say, a personal Microsoft account, they would simply be denied access at the Azure AD level itself.

Session Management and Logout: Once logged in, the user’s session with the app is managed via secure HTTP-only cookies or in-memory tokens (depending on the app specifics and Supabase’s handling). Sessions have a defined timeout (with idle timeout and absolute expiry) to reduce risk of a forgotten logged-in session being abused. Users can log out at any time, which immediately invalidates their Supabase JWT and clears tokens. If your IT team kills a session or disables a user in Azure AD, that will also invalidate their tokens shortly (Azure AD can issue token revocation events or simply not refresh tokens for disabled accounts). We recommend, and implement, relatively short token lifetimes (on the order of 1 hour for access tokens) to limit the window of misuse, combined with silent token renewal to keep UX smooth. If a user’s device is lost or they suspect compromise, normal Azure AD measures (like a password reset or account disable) propagate to our apps too – on next token validation, the app will require a fresh login.

API Security and Data Validation

Secure API Endpoints (ProptechOS): The ProptechOS platform exposes a set of RESTful APIs to interact with building data (and in some cases streaming APIs for real-time events). These APIs are protected by Azure AD as described – specifically using OAuth2 Bearer tokens. Beyond authentication, the ProptechOS APIs enforce authorization checks on each request. For example, if a user requests data for Building X, the platform checks that the user (via Azure AD group or role) has access to Building X’s data. These rules are configured in ProptechOS based on your organization’s data governance (we align API permissions with how you want data segregated – e.g., maintenance staff can see maintenance tickets, energy managers can see utility data, etc.). The ProptechOS backend also validates input data: any parameters in API calls go through schema validation. If an API expects, say, a device ID and a numeric value, it will reject malformed input (e.g., a string where a number is expected or values out of allowed range). This prevents inadvertent or malicious attempts to exploit the API with unexpected data.

Supabase Data Access Controls: On the Supabase side, all data operations use the Supabase Data API which is a secure REST interface fronting the Postgres database. We heavily rely on Row Level Security (RLS) policies in Postgres to enforce per-user data filtering. RLS is like an extra WHERE clause that the database applies automatically based on the user’s identity token. For instance, if we have a table of work orders, an RLS policy ensures each user can only select the work orders that belong to their facility or to them, unless they have an “admin” role in their token. These policies are defined in SQL within the database and are thoroughly tested. Without satisfying the policy, the database will return no rows even if the query is well-formed. This means even if a clever user tried to modify a query (or discovered the direct API endpoint), they cannot retrieve data not meant for them – the database itself will stop them. We have RLS enabled on all tables with sensitive data by default, as a critical safeguard (it’s noteworthy that a misconfiguration of RLS was the cause of a known vulnerability in early 2025 that affected many low-code apps; we have taken strict measures to avoid that by carefully enabling and testing all RLS rules. In addition to RLS, Supabase allows defining stored procedures (RPC functions) that encapsulate complex operations. We use those to ensure multi-step operations happen safely on the backend. Each RPC has its own permission settings and many perform extra validation (like “only allow this function if the user is in an Admin role” for bulk updates, etc.).

Input Validation and Sanitization: Within the Lovable application front-end, any data collected from users (e.g., form inputs, query filters) is validated before being sent to the backend. The Lovable platform’s UI components come with basic validation (for example, if a field is marked as a number or email, it will enforce the right format). We add custom validation rules in cases where business logic requires (like date ranges, allowed strings, etc.). Moreover, on the server side (Supabase Edge Functions or ProptechOS API), we treat all input as untrusted: for example, if the app allows a user to add a comment on a ticket, we will sanitize that text to prevent any script injection (this is more of an application layer concern, but we mention it to illustrate defense in depth). The database also uses column data types to enforce structure (so you cannot, say, enter a 500-character string into a field that expects a 50-character name; the database will reject it).

Prevention of Injection Attacks: Because our architecture uses parameterized queries and ORMs provided by Supabase, the risk of classic SQL injection is very low. The Supabase client libraries do not concatenate strings to build queries; they send requests as JSON RPC which the server safely translates to SQL with parameters. Additionally, our use of prepared statements in any custom function means that any user-supplied values are treated as data, not executable code. On the ProptechOS side, since it’s a well-defined API, there’s no SQL injection risk at all (the user can’t directly influence a query, they can only call allowed API methods). We do remain vigilant for other injection forms, though – such as HTML/JS injection (XSS). To combat that, any data that is displayed in the UI is rendered in a context that escapes HTML by default (Lovable apps typically use a React-like framework under the hood, which auto-escapes content). We avoid injecting raw HTML from user input. In cases where we use rich text, we sanitize it on input (for example, stripping script tags). Combined with content security policies on hosting (which restrict where scripts can load from), the apps protect against cross-site scripting. Another injection vector is command injection in backend functions – but since our backend functions (Edge Functions) are written in secure TypeScript/JavaScript and run in a sandbox, and we don’t execute OS commands based on input, this is negligible in our scenario. In summary, the system is built to treat all inputs with care and validate or sanitize them, neutralizing injection attempts.

API Abuse Protections: We have implemented several limits to prevent abuse of the APIs. Supabase, by default, can have rate limiting rules configured (and we have aligned those with expected usage patterns). If a client suddenly issues an unusually high number of requests in a short time, further requests will be throttled. This protects against both unintentional overload (a buggy script) and malicious scraping or DoS attempts. On the ProptechOS side, the Azure API Management layer (if in use) or the platform’s native throttling will similarly cap excessive calls. We also ensure that large data queries require intentional filtering – e.g., an endpoint won’t just dump all data unless specifically requested by an authorized admin, and even then, pagination is enforced. This is part of being custodians of performance and security; an uncontrolled query can both degrade service and potentially expose too much data. By requiring pagination and having sane defaults (maybe the first 100 records, etc.), we ensure that any access is deliberate and within manageable size.

Secure Communication: All API interactions occur over HTTPS with TLS 1.2+. Whether a browser is talking to the Lovable app or the app is talking to Supabase or ProptechOS, every connection is encrypted in transit. This guards against eavesdropping and man-in-the-middle attacks – no data or token can be intercepted in plaintext. Our endpoints are all served on https:// addresses and we use HSTS (HTTP Strict Transport Security) on our domains to enforce that clients always use HTTPS. The Supabase endpoints (for auth, database) similarly require HTTPS and have valid certificates. Furthermore, within our cloud environment, if any service-to-service communication were needed, it would also use secure channels or stay within a private network. For example, if ProptechOS pushes data to Supabase, it does so either via a secure direct connection or through a function call with proper authentication – never via an unencrypted channel.

Data Integrity and Validation: In addition to confidentiality, we care about integrity – ensuring data isn’t tampered with. Tokens issued by Azure AD are JWTs signed by Microsoft’s keys; the app verifies these signatures, so they cannot be forged or altered. Similarly, any data posted to ProptechOS or Supabase that’s critical can have validation checks. For instance, if a value seems out of expected range (like a sensor reading that’s impossibly high), the system can flag or reject it to prevent bogus data from being accepted (this might be more of a quality control than security, but it overlaps, as it could detect a malfunctioning sensor or a malicious attempt to feed wrong data). Where appropriate, we also log a checksum or version number with records to detect any potential inconsistent changes.

In summary, API security is enforced by strong authentication on every call, fine-grained authorization (both at the application level and within the data layer), and comprehensive input validation. Data validation occurs at multiple layers (client, server, database) to ensure that only properly formed, authorized transactions are executed. This multi-layer approach means that even if one check is missed, another will catch anomalies – reflecting a defense-in-depth posture. The result for you as a customer is confidence that data retrieved by the app is exactly what the user is allowed to see, and that any data submitted is vetted and protected throughout its journey.

Encryption (In Transit and At Rest)

Encryption in Transit: All communications between the app, users, and services are protected with modern encryption protocols. When you access a Lovable-based app in your web browser, the connection is secured with HTTPS/TLS. We use TLS 1.2+ with strong cipher suites, as recommended by industry standards, to encrypt the data traveling over the network. This means that any information exchanged – whether it’s login credentials, sensor data from ProptechOS, or personal details – is indecipherable to anyone who might intercept the traffic. The Azure AD login happens on Microsoft’s secure servers (you’ll see the login.microsoftonline.com domain with a lock icon, indicating a verified certificate). The ProptechOS API endpoints are also served only over HTTPS. Our Supabase instance is accessed via https://<project>.supabase.co endpoints, which have valid SSL certificates and require TLS for all interactions (supabase.com). In short, from the user’s browser to our backend services, every hop is encrypted. We also enable HSTS (HTTP Strict Transport Security) on our custom domains to ensure browsers don’t even attempt an insecure connection. Additionally, internal service-to-service calls (like data sync processes) either occur over TLS or within cloud infrastructure that ensures encrypted tunnels. This comprehensive in-transit encryption protects against eavesdropping (no one can “listen in” on the network to steal data) and man-in-the-middle tampering (any alteration of data in transit would break cryptographic checks and be rejected).

Encryption at Rest: Data stored in our systems is encrypted at rest to guard against unauthorized access to the underlying storage. For the Supabase database, all database files and backups are encrypted using AES-256 encryption by the Supabase managed services. This is done automatically at the disk level, meaning if someone were to somehow get hold of the raw disks or snapshots, they could not read the data without the encryption keys (which are securely managed by the cloud provider). Supabase’s encryption covers both the primary data and any backups or replicas. Additionally, Supabase encrypts sensitive configuration like access tokens and keys at the application layer before storing them.

Key Management: The encryption at rest is managed by the respective cloud services (Supabase and Azure) using their internal key management systems. Supabase, for instance, would manage the encryption keys and rotate them according to their compliance standards (Supabase is SOC2 Type 2 and even HIPAA compliant, indicating mature key management and security practices). In Azure, keys for storage encryption are likewise stored in Azure Key Vault. We also make use of Azure AD’s encryption for tokens: the tokens and secrets are ephemeral, but they are transmitted and stored (if at all) in encrypted form (e.g., the tokens in the browser are in memory or secure storage). For any configuration secrets we hold (like API keys), we use vault mechanisms (Supabase Edge Functions use a secure store, and any secrets in Lovable’s config are stored encrypted on their servers).

Application-Level Encryption (if needed): In our current use-cases, we rely on the robust encryption provided by the platform. Should there be a need to encrypt certain data fields at the application level (for instance, if storing something highly sensitive in the database that even a DBA shouldn’t easily read), we can employ libraries or Supabase’s pgcrypto functions to encrypt that data with our own keys. For example, if we needed to store tenant personally identifiable information (PII) like social security numbers (generally we avoid doing so), we could encrypt those fields such that only the application (with the encryption key) can decrypt them, adding an extra layer atop the database’s encryption. At this time, most data handled (building telemetry, user profile basics, etc.) does not require this level of encryption, but the capability exists and we would apply it for any such sensitive use-case or compliance requirement.

Device and Storage Encryption: We also consider the endpoints. Our web applications do not, by default, store large amounts of data client-side, and any sensitive token (like an access token) is stored in memory or secure cookie with HttpOnly flag, reducing its exposure on the device.

TLS for External Integrations: If our Lovable app calls any third-party services (e.g., a mapping service like Mapbox), those calls are also made over TLS. We ensure up-to-date CA certificates and enable certificate pinning where feasible for critical backends to prevent any hijack of DNS or network. We maintain strong cipher configurations and update them as new vulnerabilities (like deprecated ciphers or TLS versions) are discovered.

Deployment and Hosting Security

Lovable.dev Platform Security: The Lovable.dev platform is where the application code is built and can be hosted. Lovable takes security seriously at the platform level – it is SOC 2 Type 2 compliant and ISO 27001 certified (lovable.dev, lovable.dev), meaning it has undergone rigorous audits on how it handles user applications and data. When we deploy an app via Lovable, it runs in a cloud environment that Lovable manages, with protections such as network isolation, container sandboxing, and continuous monitoring. Each application is deployed in a separate context (for example, within its own container or function instance), ensuring that one app cannot interfere with another. Lovable has implemented a “Security Checker” tool that scans projects for common vulnerabilities or misconfigurations before and after deployment (lovable.dev). This includes scanning for exposed secrets, dangerous code patterns, and compliance with Lovable-specific security policies. While this primarily aids us as developers, it also means the platform is proactively looking out for issues. Additionally, Lovable employs 24/7 security monitoring on their infrastructure (lovable.dev), so if there were any unusual activity at the hosting level (like an attacker trying to exploit the runtime environment), their ops team would likely detect and act on it.

Hosting Environment: The Lovable application runs on a modern cloud stack. Lovable handle patching of the underlying OS, applying security updates to the runtime, and managing network firewalls. We also configure custom domains with HTTPS – meaning if the app is accessible at, say, app.company.com, we provision TLS certificates (via Let’s Encrypt) so that it’s fully secure. The deployment uses an Infrastructure as Code approach for consistency, meaning the same secure configurations are applied each time.

Network Security: At the network level, we enforce the principle of least exposure. The front-end app is accessible to end users over the internet (since these are web apps meant to be used by your team or clients), but backend components like the database are not exposed directly to the public. Supabase’s database isn’t directly reachable except through the Supabase API endpoints, which require the aforementioned auth. We also lock down communications: for example, if we set up any Supabase Edge Functions or other microservices, we can restrict their inbound access (e.g., only the Lovable app’s domain can call them, via CORS and API keys) and their outbound access (only allow them to call specific hosts like ProptechOS API). Azure AD provides an extra network isolation in the sense that ProptechOS’s API can be published either as a public endpoint (still requiring auth) or through Azure API Management with policies. We ensure no sensitive service is inadvertently left open. For example, the Supabase service role key (the admin key) is never used in client-side code, so no one can directly connect to the database with full rights.

Application Hardening: The applications themselves are hardened by configuration. We implement content security policies (CSP) in the web app to prevent it from loading scripts or iframes from unapproved sources, reducing the risk of cross-site scripting via external payloads. We disable any unnecessary features in the browser context (for instance, if an app doesn’t need to use microphone or location, we don’t request those, and modern browsers won’t allow them without prompt anyway). On the server side, error messages are sanitized so as not to leak sensitive stack traces or information to end users – detailed errors go to logs for developers, but users get generic error messages. This avoids giving attackers clues.

CI/CD and Deployment Pipeline: We use GitHub integration provided by Lovable, to export code and track changes. This means we have version control history for auditing and the ability to roll back if needed. The CI pipeline runs tests and security scans as mentioned earlier, and only then deploys to production. We deploying first to the preview environment that mirrors production to test changes in a safe space. Only authorized team members can trigger deployments, and all deployments are logged.

Physical and Cloud Security: Because we rely on cloud providers, physical security of servers is handled by them (Azure data centers and Supabase’s hosting providers have stringent physical security—guards, biometric access, CCTV, etc.). We do not run any on-premises servers for these apps, which means we avoid risks like someone walking into a server room. The cloud providers also give us high availability; for example, the Supabase database can be configured with standby replicas, and Azure services have redundancy, so the chance of downtime due to infrastructure issues is minimized (which is also a security aspect—availability is one pillar of security).

Secrets and Configuration Management

Secure Storage of Secrets: The applications and integrations use various credentials – for example, API keys for external services, database connection strings, JWT signing secrets, etc. All such secrets are stored securely and never hard-coded in application code or configuration files that could be exposed. Specifically, we use environment variable management and secret storage solutions: in Supabase Edge Functions, secrets (like a ProptechOS API key if used for server-side jobs) are stored in Supabase’s secure vault, and in Lovable, we utilize their environment configuration to inject secrets at runtime. These values are encrypted at rest by the platform and are not visible to the public or other tenants. For instance, the Azure AD client secret (used by Supabase to enable the Azure login flow) is input into the Supabase dashboard and stored securely on their sides (supabase.com, supabase.com) – it is never exposed in the client app. By design, Lovable’s front-end only contains the Supabase anon key which is a deliberately low-privilege key; all other sensitive keys remain on the server side.

No Secrets in Client-side Code: We ensure that nothing sensitive is sent to the browser that isn’t absolutely necessary. The anon key mentioned is essentially a pointer to the database project with minimal rights. Other keys – such as the Supabase service role key (which has full DB rights) – are confined to backend use only (like in cloud functions). Similarly, if the app needs to call an external API that requires a secret (like a third-party service for maps or emails), we route that through a backend function rather than exposing the secret to the front-end. This way, even if someone inspects the app’s code running in their browser or intercepts traffic, they cannot steal these secrets. This approach is aligned with best practices where the client is treated as an untrusted environment; you never put something in the client that you can’t afford to be public knowledge.

Configuration Management: We maintain separate configuration for different environments (Dev, Test, Prod). Each environment has its own set of secrets and settings, managed via environment variables. This prevents, say, a debugging or test setting from being accidentally enabled in production.

Least Privilege for Credentials: For every credential we use, we apply the principle of least privilege. The Supabase anon key, as mentioned, can only perform actions allowed to the “authenticated” Postgres role, which, with RLS, means it can only see that user’s data. The Azure AD app’s permissions are narrowly defined – for example, our Azure AD app might request permission only to read user basic profile and call ProptechOS APIs, and not, say, full read of all user directory or other Graph API permissions, unless required. If we integrate a service like an email API (for sending notifications), the API key for that service is scoped only to sending emails (not reading any account data, if the service allows). We create separate API keys for separate functions – e.g., a map service key for just map tiles (not allowing any account modifications on the map service side). This containment ensures that if any one secret were somehow compromised, the damage is limited to that service and function.

Secret Rotation: We have a schedule and process for rotating secrets periodically and on-demand. Azure AD client secrets by default have an expiration (we set a 12 month lifetime) we track these and generate new secrets before they expire, ensuring continuity and security.

Protection in Transit and Use: When secrets do need to be used (for instance, Supabase needs to use the Azure client secret to complete login, or an Edge Function uses an API key to call an external service), they are used over secure channels. Also, these secrets are not logged. We are careful to scrub or avoid logging any sensitive values. Our logging configuration omits things like passwords, keys, tokens from being written to logs. If we ever need to debug something involving a secret, we use placeholder values or do it in a safe, controlled manner. This ensures that logs (which might be more accessible) don’t inadvertently become a source of secret leakage.

Developer Access to Secrets: Access to configure or view secrets in the various platforms is restricted to a small subset of our team. Supabase project access is limited; we manage it such that developers can deploy and use the environment but not necessarily extract secrets. This internal control prevents mistakes or unauthorized internal access. We also keep an inventory of all secrets used in the system, documented in an internal vault. This inventory helps in audits and rotations (we know where each key is used and who owns it).

User Secrets and Privacy: We consider secrets in a broader sense too: user credentials (their Azure AD passwords, etc.) never touch our system – that’s entirely handled by Azure AD. We only see an email or user ID, which are not secrets. If an app allows users to store any private token (for example, maybe an integration where a user links their account to another service), we ensure those tokens are encrypted and stored safely, and only retrieved in context of that user and usage. But currently, most data is either system-managed secrets or user data in database (not user secrets).

Third-Party Secret Management: If any third-party services are involved (like if ProptechOS needed to share a credential with us for access), we handle that through secure channels and avoid email/plaintext sharing. For instance, exchanging API credentials happens via secure vault links or direct input into our systems. We treat your secrets (should there be any you provide, like integration keys) with the same care as our own. They would be stored encrypted and only used for the intended purpose.

Configuration Change Tracking: We have logging for configuration changes. For example, Azure AD has an audit log – if someone changes a setting on the app registration, that’s recorded. Supabase logs administrative actions like changing auth settings or secrets. We also maintain an internal changelog whenever we update environment configs. This way, if an issue arises, we can review recent config changes to pinpoint potential causes or unauthorized alterations.

In essence, secrets management is about keeping the keys to the kingdom safe – we ensure that keys, tokens, and sensitive config data are kept in locked vaults (figuratively speaking) and only brought out when needed, and even then, handled over secure channels. The result is that the risk of secret leakage is minimized. Even in the unlikely event that an attacker got into the front-end code or one of the systems, they would not find plaintext secrets lying around. This dramatically reduces the risk of a breach escalating – for example, even if someone found a vulnerability in the web app, they couldn’t use it to extract the database password because it’s not there to grab. Our disciplined approach to secret rotation and scoping further ensures that if something seems off, we can quickly neutralize any credential by rotating it, without major disruption. We also align with any of your requirements for secrets: if you have a policy that API keys must rotate every N days, we can accommodate that as part of our operations.

Monitoring and Logging

Comprehensive Logging: Our system generates logs at each critical layer to create an audit trail and support monitoring. Key types of logs include:

• Authentication Logs: Azure AD provides logs of user sign-ins, including successful and failed login attempts, MFA prompts, device info, and location. We have access to these logs through the Azure portal (and can forward them to a SIEM if needed). These logs let us see, for example, if someone’s attempting to log in with a valid username but failing MFA repeatedly, or if a login comes from an unusual country. 
• Application Logs: The Lovable app can be instrumented to produce activity logs (user actions like “User A viewed page X”, “User B submitted form Y”). We configure the app to log important events and errors. This might be done via a logging service integrated with the app (some Lovable deployments allow connecting to external logging or using browser console logs that feed to an analytics service). We focus on logging security-relevant events: e.g., when an API call is made to ProptechOS, we log the endpoint and result (not the full data for privacy, but that it happened). Also, any administrative actions in the app (like if there’s an admin panel) are logged with who did what. 
• Supabase Logs: Supabase offers logs for all database queries, function calls, and authentication events (supabase.com). We enable logging of queries (with timing and user ID context) so we can audit data access. For example, we could later see that “User X retrieved 50 rows from the WorkOrders table at 10:05 AM” which is useful if there’s a suspicion of misuse. Supabase also logs errors at the database level (like if a query is blocked by RLS, etc., which is actually a good sign of RLS doing its job). We subscribe to these logs through the Supabase dashboard and have the option to export them to external storage for longer retention. 
• ProptechOS Audit Trails: The ProptechOS platform itself keeps audit trails of changes. For instance, if a user changes a property’s data or actuates a device, ProptechOS logs that action with timestamp and user identity. It also likely logs read access for sensitive data (depending on the feature). We coordinate to ensure those logs are accessible to us or to you for review. 
• Infrastructure Logs: Azure provides logs for network and infrastructure. Lovable’s platform monitors its infrastructure for anomalies (though those logs aren’t directly exposed, any incident on their side would be communicated via their trust center). We also rely on Cloudflare or similar WAF logs if employed (like logs of blocked suspicious traffic). 

Incident Response Integration: Our monitoring is tied into our incident response process (more on that in the next section). We have designated individuals on call to receive alerts. For critical alerts (like a suspected data breach, or detection of malware), we have automated escalation – e.g., an SMS or phone call in addition to email and slack notification, to ensure it’s seen. We also integrate with your team’s communication if desired; for instance, if you want to be notified of certain events (like all admin logins after hours), we can set up an alert to email your security contact or feed into your SIEM as well.

Privacy Consideration in Logging: We balance logging with privacy. We avoid logging personal data content. Typically, technical logs have minimal personal info (mostly user IDs, which can be correlated to names if needed but are not human-readable on their own).

Summary & Assurance

In this white paper, we have detailed the architecture and security model of our Lovable.dev-based applications integrated with ProptechOS, Supabase, and Azure AD. We’ve shown how security is embedded at every layer – from the use of Azure AD for rock-solid authentication, to granular data access controls in the database.

For your organization, this means you can confidently adopt and expand these applications, knowing they are built on secure foundations. Your data remains your data – under your control and isolated from others, with transparency on where and how it’s processed. Our practices align with industry standards and regulatory expectations, even if we don’t always name the standards (you’ll find we meet the spirit of GDPR, and our providers carry SOC2, ISO27001, and other attestations (lovable.devsupabase.com). The security controls in place are not static; we continuously update and improve them as new threats emerge and as your needs evolve.

We also want to underscore the shared responsibility aspect: while we commit to securing the application and cloud infrastructure, your active involvement in securing identities and following best practices is key to a holistic defense. Together, by each handling our part, we create a defense-in-depth that is very resilient.

Thank you for entrusting us with your application needs and data. We are committed to upholding that trust through continued vigilance, transparency, and partnership in security.

For any further information or specific security inquiries, please contact our security team at [email protected]. We are happy to provide additional details or arrange a workshop with your security architects to walk through any aspect of this white paper.