Lovable Application Architecture with ProptechOS
Speed and Ease of Vibe Coding with Enterprise-Grade Security
Production Applications on ProptechOS with Lovable and other AI tools
2. Vibe Coding Risks — and How This Architecture Eliminates Them
5. Authorization & Data Access Control
7. Application Deployment & Hosting
8. Source Code Management & Business Continuity
9. Platform Supply Chain Security & Compliance
10. Data Processing Agreement & DPA Coverage
11. ProptechOS Operational Responsibilities
1. Executive Summary
AI-assisted development (“vibe coding”) is transforming how business applications are built. Tools like Lovable, Bolt, and Cursor allow domain experts, building managers, and operations teams to create purpose-built applications in hours rather than months. The code these tools generate is not inherently insecure — but the primary value of vibe coding is that it can be wielded by non-developers, who are not trained to identify insecure patterns and who cannot reliably review the security and quality of the end product.
This document describes an architecture where ProptechOS, as the data and authentication platform, combined with a defined service offering, makes the overall application secure by architecture and by design — regardless of who wrote the code or how it was generated.
Key principle: Rather than attempting to make vibe-coded applications secure through code review alone (a battle that scales poorly), this architecture eliminates the categories of vulnerability that vibe coding typically introduces. The application has no secrets to leak, no database to misconfigure, no backend to exploit, and no authorization logic to get wrong. Security is enforced by the platform, not by the application code.
The Architecture Advantage
Industry research shows that 45% of AI-generated code contains security vulnerabilities (Veracode, 2025), and studies consistently find hardcoded credentials, missing access controls, and injection flaws in vibe-coded applications. The ProptechOS architecture neutralizes these risks structurally: the application simply cannot contain credentials (it has none), cannot misconfigure database access (it has no database), and cannot bypass authorization (it is enforced server-side by ProptechOS). The result is that applications built on this architecture are immune to the most common and serious vibe coding vulnerabilities by design.
2. Vibe Coding Risks — and How This Architecture Eliminates Them
Before describing the architecture in detail, it is important to understand the security landscape of AI-assisted development. Extensive research from Veracode, Wiz, Databricks, OWASP, Kaspersky, and others has documented the common vulnerabilities introduced by vibe coding. The table below maps each documented risk to its status in the ProptechOS architecture.
Documented vibe coding risk | Status | How the architecture addresses it |
Hardcoded API keys, secrets, and credentials in client-side code | Eliminated | The application has no API keys, client secrets, database passwords, or tokens. Authentication is delegated to Entra ID; all API calls use short-lived OAuth bearer tokens obtained at runtime. There is nothing to hardcode. |
Missing or misconfigured database access controls (e.g. Supabase RLS) | Eliminated | The application has no database. All data is stored in and served by ProptechOS, which enforces Resource Permission Policies (RPPs) server-side on every request. The developer cannot misconfigure what does not exist in their code. |
SQL injection and NoSQL injection | Eliminated | The application does not construct database queries. It calls the ProptechOS REST API with structured requests. SQL injection is architecturally impossible because there is no SQL layer in the application. |
Broken authentication (weak passwords, no MFA, custom login logic) | Eliminated | Authentication is fully delegated to Microsoft Entra ID. The application has no login form, no password logic, and no session management. MFA, password policies, and conditional access are enforced by the customer’s Entra ID tenant. |
Broken access control (unauthenticated endpoints, missing authorization) | Eliminated | Authorization is enforced server-side by ProptechOS RPPs on every API call. Even if the application code fails to check permissions, ProptechOS will reject unauthorized requests. The application cannot bypass this enforcement. |
Exposed or misconfigured backend servers | Eliminated | The application has no backend server. It is a set of static files (HTML, CSS, JavaScript) served from a CDN or static host. There is no server to misconfigure, no ports to leave open, no runtime to patch. |
Sensitive data exposure through error messages or debug info | Eliminated | The application has no server-side code that could leak stack traces or internal system details. Error messages from ProptechOS API are controlled by ProptechOS, not by the application. |
Insecure data storage (client-side persistence of sensitive data) | Eliminated | The application stores no data locally. All state resides in ProptechOS. The browser session holds only a short-lived bearer token in memory. |
Excessive permissions / privilege escalation | Eliminated | RPPs enforce least-privilege access per user, per resource. Permissions are managed by administrators in ProptechOS, not by application code. A developer cannot accidentally grant broad access. |
Platform vendor lock-in and hosting dependency | Eliminated | Source code is synced to ProptechOS Git. The static application can be rebuilt and redeployed to any hosting provider in under one hour using standard npm tooling. |
Vulnerable third-party dependencies (npm packages) | Mitigated | ProptechOS performs pre-production dependency audits and provides ongoing maintenance including security patching. Lovable’s Security Checker also scans dependencies before deployment. Impact is limited because the application has no backend — a compromised frontend dependency cannot access data without valid tokens. |
Cross-site scripting (XSS) | Mitigated | Modern frameworks (React, Vue) auto-escape output by default. Even if XSS is achieved, the attacker is limited to the current user’s session and token — ProptechOS still enforces RPP-scoped authorization server-side. CSP headers are recommended as an additional layer. |
Missing rate limiting / denial of service | Mitigated | Rate limiting is enforced at the ProptechOS API layer, not in the application. The application developer does not need to implement rate limiting — it is a platform concern. |
No input validation / sanitization | Mitigated | ProptechOS validates all API inputs server-side (schema validation, type checking, range constraints). Client-side validation is defense-in-depth, not the primary control. Pre-production code review verifies appropriate input handling. |
Of the 14 most commonly documented vibe coding vulnerabilities, this architecture fully eliminates 10 and significantly mitigates the remaining 4. The mitigated risks (dependencies, XSS, rate limiting, input validation) are addressed through platform-level controls and pre-production review rather than relying on the application developer to implement them correctly. This is the core advantage of the architecture: security is a property of the platform, not a responsibility of the vibe coder.
Sources
Risk categories compiled from: Veracode GenAI Code Security Report (2025), Wiz vibe coding security research, Databricks AI Red Team findings, OWASP Top 10 for LLM Applications, OWASP Top 10 for Web Applications, Kaspersky vibe coding risk analysis, Tenzai vibe coding vulnerability assessment (2025), and the Vibe Coding Security Top 10 (vibesecurity.io).
3. Architecture Overview
The system consists of three distinct layers, each with clearly defined responsibilities and trust boundaries. Understanding this separation is critical to evaluating the security posture of the overall solution.
3.1 Architecture Layers
Layer | Component | Responsibility |
Presentation | Stateless web app (Lovable / Bolt / etc.) | User interface rendering, UX logic. Contains no secrets, keys, or data. |
Identity | Microsoft Entra ID (B2C) via ProptechOS | User authentication, token issuance, session management, MFA. |
Platform | ProptechOS | Data storage, API gateway, authorization (RPP), audit logging, business logic. |
3.2 Architecture Diagram
The following diagram illustrates the complete architecture, showing the trust boundaries between the user’s browser, Microsoft Entra ID, the development platform, and the ProptechOS data platform. Note that the web application (left) contains no secrets, no data, and no server-side code — all security-critical operations happen in the identity layer (top center) and the ProptechOS platform (right).
Figure 1: System architecture — stateless web application with delegated authentication and authorization. All data flows are over TLS 1.2+. The application has multiple views and routes (/, /tenants, /metrics, etc.) but remains a stateless, server-free deployment.
3.3 Trust Boundaries
The architecture enforces two critical trust boundaries:
- Browser ↔ Identity Provider: Authentication flows are handled entirely by Microsoft Entra ID. The application never sees or handles user credentials. Tokens are issued directly to the browser by Entra ID via standard OAuth 2.0 / OpenID Connect flows.
- Browser ↔ ProptechOS API: All data requests carry a bearer token validated by ProptechOS. The application has no stored credentials, API keys, or service account tokens. Every request is individually authorized against the user’s Resource Permission Policy (RPP).
Critically, there is no trust boundary between the application and any backend server it controls, because the application does not have a backend server. It is a static file deployment with no server-side code, no database connections, and no stored secrets.
4. Authentication
Authentication is fully delegated to Microsoft Entra ID (B2C) through ProptechOS. The application never implements its own authentication logic, never stores credentials, and never manages sessions directly.
4.1 Authentication Flow
- User navigates to the web application (hosted as static files).
- The application redirects to Microsoft Entra ID via the ProptechOS authentication endpoint.
- User authenticates with their organizational credentials (including MFA if configured by their tenant).
- Entra ID issues an OAuth 2.0 access token and ID token to the browser.
- The application uses the access token as a bearer token for all ProptechOS API calls.
- ProptechOS validates the token on every request and enforces authorization policies.
4.2 Security Properties
Property | Implementation |
No stored credentials | The application contains no passwords, API keys, client secrets, or service account tokens. Authentication is delegated entirely to Entra ID. |
MFA support | Multi-factor authentication is configured at the Entra ID tenant level. The application inherits whatever MFA policy the customer’s IT department enforces. |
SSO integration | Users authenticate with their existing organizational identity. No separate accounts or passwords are created for the application. |
Token-based sessions | Sessions are governed by OAuth 2.0 token lifetimes configured in Entra ID. Token refresh is handled by the MSAL library. No server-side session state exists. |
Conditional access | Entra ID Conditional Access policies (device compliance, location restrictions, risk-based access) are enforced transparently. The application does not and cannot bypass these policies. |
5. Authorization & Data Access Control
Authorization is enforced server-side by ProptechOS through Resource Permission Policies (RPPs). The application has no ability to bypass, modify, or influence authorization decisions.
5.1 Resource Permission Policies
Each authenticated user in ProptechOS is assigned one or more Resource Permission Policies that define precisely which resources (buildings, floors, rooms, sensors, actuators, etc.) the user may access and which operations (read, write, actuate) they may perform. These policies are evaluated on every API call, server-side, before any data is returned.
- Principle of least privilege: Users only see and interact with the resources explicitly granted by their RPP. A building manager in Stockholm cannot access sensor data from a building in Gothenburg unless their RPP explicitly allows it.
- Server-side enforcement: Authorization is never checked in the browser. Even if the application’s JavaScript were modified by a malicious actor, the ProptechOS API would still enforce the correct permissions.
- Granular control: RPPs can restrict access at multiple levels: by real estate, building, floor, room, or even individual device. Operations can be scoped to read-only, read-write, or actuation-permitted.
IT Department Control
RPPs are configured by system administrators in ProptechOS, not by the application or its developers. This means the customer’s IT department retains full control over who can access what data, regardless of how many applications are built on top of ProptechOS.
6. Data Security & Storage
All application data is stored and served exclusively by ProptechOS. The application stores no data locally (beyond what the browser caches in normal operation) and maintains no database, file store, or persistent state of its own.
6.1 Data Flow
- The application requests data from the ProptechOS API, passing the user’s bearer token.
- ProptechOS validates the token, evaluates the user’s RPP, and returns only the data the user is authorized to see.
- Data is rendered in the browser and exists only in memory for the duration of the session.
- No data is written to local storage, IndexedDB, or other browser persistence mechanisms by the application. (Standard browser caching of HTTP responses may apply and is governed by cache headers set by ProptechOS.)
6.2 Security Properties
Property | Details |
Encryption in transit | All communication between the browser and ProptechOS is over TLS 1.2+. Certificate management is handled by ProptechOS infrastructure. |
Encryption at rest | Data stored in ProptechOS is encrypted at rest using platform-level encryption managed by ProptechOS’s cloud infrastructure. |
No client-side data storage | The application does not persist data locally. All state resides in ProptechOS. Closing the browser tab effectively ends the session. |
Data residency | Data residency is determined by the ProptechOS deployment, not by the application. Customers with data residency requirements address them at the ProptechOS platform level. |
No data exposure to third parties | The application does not send data to any third-party service, analytics platform, or external API. All data flows are between the browser and ProptechOS. |
7. Application Deployment & Hosting
Applications built with this architecture are stateless web applications consisting entirely of HTML, CSS, and JavaScript files. They contain no server-side code, no backend processes, and no runtime dependencies beyond a web browser and the ProptechOS API.
7.1 What the application contains
- HTML, CSS, and JavaScript files (the compiled output of React, Vue, or similar frameworks).
- Configuration for the ProptechOS API endpoint URL and the Entra ID tenant/client identifiers (all public values, not secrets).
- No API keys, client secrets, database connection strings, or any other sensitive configuration.
7.2 What the application does NOT contain
- No server-side code (no Node.js, Python, Java, .NET, or other backend runtime).
- No database connections or direct access to any data store.
- No stored credentials, tokens, or secrets of any kind.
- No business logic that bypasses ProptechOS authorization.
- No outbound connections to services other than ProptechOS and Microsoft Entra ID.
7.3 Hosting Model
Because the application is a set of static files, hosting is trivial and inherently low-risk. Options include:
- ProptechOS-hosted: ProptechOS can serve the static files directly, keeping the entire stack within the ProptechOS trust boundary.
- CDN / static hosting: Services like Azure Static Web Apps, AWS CloudFront/S3, Netlify, or Vercel can host the files. Since the files contain no secrets, the hosting environment has no access to customer data.
- Customer-managed: Customers can host the files on their own web servers or internal CDN if organizational policy requires it.
Cost & Complexity Implication
Static file hosting is among the simplest and cheapest forms of web hosting. There are no application servers to patch, no runtime environments to maintain, and no database servers to secure. This dramatically reduces both the cost and the operational burden of running business applications.
8. Source Code Management & Business Continuity
A common concern with AI-assisted development platforms (Lovable, Bolt, etc.) is vendor dependency: what happens if the platform changes its business model, experiences downtime, or ceases operations? This architecture addresses that concern through source code portability.
8.1 Source Code Synchronization
All application source code is synchronized to ProptechOS Git, a Git-based source control service managed by ProptechOS. This provides:
- Full source ownership: The customer and ProptechOS retain a complete copy of the application source code at all times. The source is not locked inside the vibe-coding platform.
- Platform independence: If the development platform becomes unavailable, the source code can be built, modified, and deployed using standard development tools (npm, yarn, any CI/CD pipeline).
- Version history: Git provides full version history, enabling rollback, audit trail, and change tracking.
8.2 Deployment Fallback
Should the original hosting or development platform become unavailable, the following recovery path is available:
- Clone the source repository from ProptechOS Git.
- Build the application using standard tooling (e.g., npm run build).
- Deploy the resulting static files to any hosting provider (see Section 7.3).
- No changes to authentication, authorization, or data access are required — the application continues to work against ProptechOS and Entra ID as before.
This recovery process can typically be completed in under one hour by any developer familiar with modern JavaScript tooling.
9. Platform Supply Chain Security & Compliance
A critical concern for IT departments evaluating this architecture is the security posture of the entire supply chain — not just the application itself, but the platforms used to build, host, and operate it. This section documents the compliance certifications and security practices of each component in the stack.
9.1 Lovable — Development & Hosting Platform
Lovable (lovable.dev), the AI-assisted development platform used to build the application, maintains enterprise-grade security certifications and practices:
Certification / Practice | Details |
SOC 2 Type II | Lovable has been SOC 2 Type II compliant since August 2025, demonstrating independently audited controls over security, availability, and confidentiality of customer data and applications. |
ISO 27001:2022 | Lovable holds ISO 27001:2022 certification, the international standard for information security management systems (ISMS). This covers their development platform, hosting infrastructure, and operational processes. |
GDPR Compliance | Lovable is GDPR compliant and provides a Data Processing Agreement (DPA). Lovable Labs AB is headquartered in Stockholm, Sweden. A DPO has been appointed. |
Security Checker 2.0 | Lovable automatically scans generated code, dependency trees, and database configurations for vulnerabilities and exposed secrets before deployment. Findings are categorized by severity and surfaced to developers. |
Platform Safety | AI-powered threat detection evaluates against 20+ security policies. Blocks malware, phishing, and impersonation prompts. 24/7 security monitoring and audit. WAF controls, network isolation, and adaptive rate limiting. |
Application Isolation | Each application is deployed in a separate container context with distinct runtime isolation. Applications cannot access each other’s data or execution environments. |
Important distinction: Lovable’s certifications cover the development and hosting platform. In this architecture, Lovable does not process, store, or have access to customer building data or personal data — that is handled exclusively by ProptechOS. Lovable’s role is limited to hosting the static application files. Even if Lovable’s infrastructure were compromised, the attacker would gain access only to the application’s HTML/CSS/JavaScript (which is not secret) and would still need valid Entra ID tokens and ProptechOS RPP authorization to access any data.
9.2 Microsoft Entra ID — Identity Provider
Microsoft Entra ID (formerly Azure AD B2C) is one of the most widely audited identity platforms in the world. It holds SOC 1/2/3, ISO 27001, ISO 27018, CSA STAR, and FedRAMP certifications, among others. Its compliance portfolio is publicly documented in the Microsoft Service Trust Portal. The customer’s own Entra ID tenant policies (MFA, conditional access, device compliance) apply to all applications in this architecture without modification.
9.3 ProptechOS — Data Platform
ProptechOS serves as the data processor for all building and operational data. ProptechOS’s security practices, DPA, and infrastructure are covered in detail in the ProptechOS security documentation and in the existing customer agreement. ProptechOS runs on Azure infrastructure, inheriting Azure’s physical security, network isolation, and compliance certifications.
9.4 NIS2 Directive Alignment
The EU NIS2 Directive (Network and Information Security Directive 2) sets baseline cybersecurity requirements for organizations operating in critical and important sectors across the EU. While NIS2 is a regulatory directive (not a certifiable standard), the architecture described in this document aligns with its core requirements:
NIS2 Requirement | How This Architecture Addresses It |
Risk management measures | All platform components (Lovable, ProptechOS, Entra ID) maintain formal risk management processes verified through SOC 2 and ISO 27001 audits. ISO 27001 covers approximately 70% of NIS2 requirements. |
Incident reporting | ProptechOS maintains an incident response process. Lovable commits to notifying affected customers within 72 hours of a confirmed breach. These align with NIS2’s 24-hour early warning and 72-hour notification requirements. |
Supply chain security | All components in the supply chain (Lovable, Entra ID, ProptechOS) hold independent security certifications. The architecture minimizes the supply chain by using only three trusted components, each with audited security controls. |
Access control & encryption | Centralized identity via Entra ID with MFA. Role-based authorization via ProptechOS RPPs. TLS 1.2+ for all data in transit. AES-256 encryption at rest. |
Business continuity | Source code in ProptechOS Git enables recovery independent of any single platform. Stateless web application architecture means redeployment in under one hour. No single point of failure for data (ProptechOS on Azure with redundancy). |
Vulnerability management | Lovable’s Security Checker scans code and dependencies pre-deployment. ProptechOS performs pre-production code reviews. Ongoing dependency monitoring for known CVEs. |
Compliance Through Architecture
Rather than requiring each application to independently achieve compliance, this architecture inherits compliance from its platform components. The SOC 2 Type II and ISO 27001 certifications of Lovable, combined with Entra ID’s extensive compliance portfolio and ProptechOS’s DPA and security practices, create a compliance baseline that individual applications automatically benefit from. This significantly reduces the compliance burden for IT departments approving new applications.
10. Data Processing Agreement & DPA Coverage
A key advantage of this architecture is that it consolidates all data processing under a single, well-defined legal and contractual framework. Because the application stores no data and performs no server-side processing, the entire data processing chain falls under the existing Data Processing Agreement (DPA) between the customer and ProptechOS.
10.1 Single DPA Coverage
In a traditional application architecture, multiple DPAs may be required: one with the hosting provider, one with the database provider, one with the application backend operator, and potentially others with third-party services. Each DPA introduces contractual complexity and additional compliance obligations.
With this architecture, the picture is fundamentally simpler:
- All personal data processing is performed by ProptechOS. The application is a presentation layer that renders data in the browser. It does not process, transform, store, or transmit personal data to any party other than ProptechOS.
- The customer’s existing DPA with ProptechOS covers the application. No additional data processing agreements are required for the application itself, its hosting provider, or the vibe-coding development platform (which has no access to production data).
- Sub-processor management is handled by ProptechOS. ProptechOS maintains and communicates its sub-processor list as part of its DPA obligations. The customer does not need to manage sub-processors for the application layer.
DPA Simplification
Instead of managing multiple data processing agreements across hosting, database, backend, and third-party services, the customer has a single DPA with ProptechOS that covers all data processing for all applications built on the platform. This is a significant reduction in legal and compliance overhead.
10.2 GDPR & Data Protection
From a data protection perspective, the application itself processes no personal data beyond what is displayed to the authenticated user in their browser session. All data processing, storage, and access control happens within ProptechOS, which serves as the data processor (or sub-processor) under the customer’s data processing agreement.
- No personal data is stored in the application or its hosting environment.
- No personal data is transmitted to third parties by the application.
- Data subject access requests are handled at the ProptechOS level, not the application level.
10.3 Audit & Logging
ProptechOS provides centralized audit logging for all API access. Every data request made by the application is logged with the authenticated user’s identity, the requested resource, the action performed, and a timestamp. This audit trail is available to the customer’s IT department and is independent of the application itself.
10.4 Change Management
Changes to the application are tracked in Git (ProptechOS Git). Organizations that require formal change management can integrate the Git repository with their existing approval workflows, pull request reviews, and deployment pipelines. The use of a vibe-coding tool for initial development does not prevent the application from being managed through standard IT change management processes going forward.
11. ProptechOS Operational Responsibilities
ProptechOS does not merely provide a data platform — it takes active operational responsibility for applications built on its architecture. This section outlines the commitments that ProptechOS makes to ensure applications remain secure, functional, and maintained over their lifecycle.
11.1 Pre-Production Validation
Before any vibe-coded application is approved for production use, ProptechOS performs a formal architecture and code review. This review serves as a quality gate ensuring that the application conforms to the security model described in this document.
The pre-production validation includes:
11. Architecture review: Verification that the application follows the stateless web application pattern — no backend servers, no stored secrets, no direct database access, and all data access routed through the ProptechOS API.
12. Code review: Inspection of the source code for security issues, including hardcoded credentials, insecure API usage, unprotected routes, and unauthorized third-party dependencies or data exfiltration patterns.
13. Authentication flow validation: Confirmation that authentication is correctly delegated to Microsoft Entra ID via ProptechOS, and that no custom authentication logic exists in the application.
14. Authorization testing: Verification that the application correctly relies on ProptechOS RPPs and does not implement client-side authorization logic that could be bypassed.
15. Dependency audit: Review of third-party npm packages for known vulnerabilities and license compliance.
Pre-Production Gate
No application is deployed to production without passing ProptechOS’s pre-production validation. This review provides an independent verification that the application meets enterprise security standards, regardless of how it was developed. The review results are documented and can be shared with the customer’s IT department as part of their approval process.
11.2 Ongoing Maintenance & Security
ProptechOS takes responsibility for the ongoing maintenance of applications built on the platform. This includes incremental improvements for minor features, bug fixes, and — critically — security maintenance to ensure applications remain compliant and protected over time.
The maintenance commitment covers:
- Security patching: When vulnerabilities are discovered in application dependencies (npm packages, JavaScript libraries), ProptechOS coordinates the update and redeployment of affected applications.
- Platform compatibility: As the ProptechOS API evolves, ProptechOS ensures that applications built on the platform continue to function correctly and are updated to leverage new API capabilities or conform to API changes.
- Minor feature improvements: ProptechOS can implement incremental improvements — UI refinements, new data visualizations, additional filters or views — as part of its ongoing service to maintain and improve the application over time.
- Incident response: If a security incident affects the application layer (e.g., a compromised dependency), ProptechOS takes responsibility for the remediation and communicates with the customer’s IT department as part of the established incident response process.
Responsibility | Owner |
Platform infrastructure & API | ProptechOS |
Authentication & identity | Microsoft Entra ID (managed via ProptechOS configuration) |
Authorization (RPP management) | ProptechOS (configuration by customer admin) |
Pre-production code review | ProptechOS |
Application maintenance & security | ProptechOS |
Data processing (DPA) | ProptechOS (under existing customer DPA) |
User access management | Customer IT department (via Entra ID & ProptechOS RPPs) |
12. Risk Assessment Summary
The following table summarizes the key risk areas and how this architecture addresses them.
Risk Area | Risk Level | Mitigation |
Credential theft | Low | No credentials stored in the application. Authentication delegated to Entra ID. |
Unauthorized data access | Low | Server-side RPP enforcement. Application cannot bypass authorization. |
Data exfiltration | Low | No client-side data storage. No third-party data sharing. Data only in ProptechOS. |
Platform vendor lock-in | Low | Source code synced to ProptechOS Git. Standard tooling for build and deploy. |
Application tampering (XSS) | Low–Medium | Even if application code is tampered with, ProptechOS enforces authorization server-side. Impact is limited to the individual user’s session. Standard CSP headers recommended. |
Hosting provider outage | Low | Static files can be redeployed to any hosting provider. Recovery time: under one hour. |
Server-side vulnerabilities | Not Applicable | No server-side code exists in the application layer. All server-side logic is in ProptechOS (managed service). |
13. Recommendations for IT Departments
When evaluating applications built with this architecture, IT departments should consider the following:
13.1 Review Checklist
✓ | Check | Expected Result |
□ | Verify no secrets in source code | No API keys, client secrets, or tokens in the repository. Only public configuration (tenant ID, API URL). |
□ | Verify authentication flow | Application redirects to Microsoft Entra ID. No custom login forms. MSAL library used for token management. |
□ | Verify RPP assignment | Users accessing the application have appropriate RPPs configured in ProptechOS limiting data access to their scope. |
□ | Review outbound network calls | Application communicates only with ProptechOS API and Microsoft Entra ID. No calls to unknown third-party services. |
□ | Confirm source code in Git | Application source code is present and current in ProptechOS Git repository. |
□ | Test authorization boundaries | Authenticated users can only access data permitted by their RPP. Attempts to access unauthorized resources return errors. |
□ | Review CSP headers | Content Security Policy headers restrict script sources and prevent inline script execution where possible. |
□ | Confirm data handling | No personal or building data stored in browser local storage, cookies, or IndexedDB by the application. |
□ | Confirm pre-production review | Application has passed ProptechOS pre-production architecture and code review before going live. |
□ | Verify DPA coverage | All data processing falls under the existing ProptechOS DPA. No additional DPAs required for the application layer. |
□ | Confirm platform certifications | Lovable (SOC 2 Type II, ISO 27001:2022), Entra ID (SOC 1/2/3, ISO 27001, FedRAMP), ProptechOS (Azure infrastructure, customer DPA) all hold current certifications. |
13.2 Ongoing Governance
- Periodic RPP review: Regularly audit Resource Permission Policies to ensure users have appropriate access levels.
- Token lifetime management: Configure Entra ID token lifetimes and refresh policies according to organizational security requirements.
- Dependency monitoring: Use tools like Dependabot or Snyk to monitor the application’s npm dependencies for known vulnerabilities.
- Source code reviews: Even for vibe-coded applications, periodic code reviews can verify that no secrets have been accidentally introduced and that data handling remains compliant.
14. Conclusion
Applications built with rapid development tools on ProptechOS achieve a security posture that is, in many respects, stronger than traditional application architectures. By eliminating the backend server entirely, the architecture removes entire categories of risk: there are no server-side vulnerabilities to patch, no database credentials to protect, no session stores to secure, and no API keys to rotate.
The combination of Microsoft Entra ID for authentication, ProptechOS Resource Permission Policies for authorization, and a stateless web application for presentation creates a clean separation of concerns where the security-critical decisions are made by purpose-built, enterprise-grade platforms — not by application code.
Furthermore, ProptechOS’s commitments to pre-production validation, ongoing maintenance, and consolidated DPA coverage mean that the customer’s IT department is not left to manage the application independently. ProptechOS acts as a responsible partner throughout the application lifecycle — from initial code review through ongoing security maintenance — under a single contractual and legal framework.
IT departments evaluating these applications should focus their review on verifying the properties described in this document: that no secrets are stored in the application, that authorization is enforced server-side, that data resides only in ProptechOS, that the application has passed pre-production review, and that all data processing is covered by the existing ProptechOS DPA. Applications that pass these checks can be confidently approved for production use.
