Skip to content

Security Design and Considerations

Security is paramount in a system like Devity that dynamically controls application UI and potentially interacts with sensitive data and backend APIs. This document outlines key security considerations and design principles.

1. Authentication & Authorization

1.1 Web Console Access

  • Authentication: Users (Developers, Designers, PMs) must authenticate securely to access the Web Console. Standard methods like email/password (with proper hashing), SSO (e.g., Google, SAML) should be supported.
  • Authorization (RBAC): Implement Role-Based Access Control (RBAC) within the Console.
    • Define roles (e.g., Admin, Editor, Viewer).
    • Assign permissions to roles (e.g., create/edit specs, approve publishing, manage users, view analytics).
    • Assign users to roles, potentially on a per-project or per-team basis.

1.2 Backend API Access

  • Console-to-Backend: APIs used by the Web Console must be protected. Session management (e.g., secure cookies, JWT tokens) should be used after user login.
  • SDK-to-Backend (Debug/Direct Mode): If the SDK communicates directly with the backend (e.g., for debug spec fetching), this channel needs secure authentication. API Keys (apiKey provided during SDK initialization) are a common approach. Keys must be securely managed and potentially scoped.
  • API Key Security: API Keys used by the SDK should be treated as sensitive credentials. Avoid hardcoding them directly in client code where possible (use build configurations, secure storage). Consider key rotation capabilities.

1.3 Action-Triggered API Calls (ApiCall Action)

  • Authentication Forwarding: Decide how authentication is handled for API calls triggered via the ApiCall action from the Client SDK to your application's backend.
    • Option 1 (Recommended): The SDK makes calls to your backend, which already has the user's authentication context (e.g., session token). The ApiCall action might only specify the relative path and method.
    • Option 2 (Less Secure): The Spec includes sensitive tokens/credentials to be passed in headers. This is generally discouraged as it embeds secrets in the potentially cacheable Spec JSON.
    • Option 3: The Devity backend proxies calls (adds complexity and potential bottleneck).
  • Authorization: Your application backend remains responsible for authorizing API calls initiated via SDUI, just like any other client request.

2. Spec Security

2.1 Secure Delivery (CDN)

  • Use HTTPS for all communication (Console-Backend, Backend-CDN, SDK-CDN, SDK-Backend).
  • Configure CDN appropriately (e.g., restrict access methods, potentially use signed URLs if needed, though often API key validation on SDK side is sufficient).

2.2 Preventing Malicious Specs

  • Input Validation: The Backend must rigorously validate all data coming from the Web Console before storing or publishing Specs. Prevent injection of malicious scripts or unexpected structures.
  • Sandboxing (SDK): The SDK acts as a sandbox.
    • It should only interpret known, registered Renderers, Widgets, and Actions.
    • It should limit the scope of what Actions can do (e.g., prevent arbitrary code execution).
    • Custom Actions/Widgets are the responsibility of the app developer but should be registered carefully.
  • Expression Engine Security: The expression engine used by the SDK must be secure against executing arbitrary code or accessing unintended system resources.
  • ApiCall Security: Limit the scope of ApiCall. Avoid allowing Specs to call arbitrary external URLs if possible; ideally, calls should target pre-approved domains or only the application's own backend.

3. Data Security & Privacy

  • Sensitive Data Handling: Avoid storing sensitive user data directly within Specs whenever possible. Fetch required data dynamically via secure API calls.
  • Data Minimization: Only include necessary data bindings and parameters in Specs and Actions.
  • Compliance: Consider relevant data privacy regulations (GDPR, CCPA, etc.) in how data is handled and logged.

4. Auditing & Monitoring

  • Audit Logs: The Backend should maintain audit logs for critical actions: user logins, Spec creation/modification/publishing, role changes, etc.
  • Monitoring: Monitor system health, API usage, CDN traffic, and potential security events.

5. Best Practices

  • Regularly update dependencies (Backend, Console, SDK) to patch vulnerabilities.
  • Perform security reviews and penetration testing.
  • Follow secure coding practices across all components.
  • Educate users (console users, developers) on security best practices (e.g., API key management).

(This document provides a high-level overview. Detailed implementation plans for authentication, RBAC, API security, etc., are required.)