Knowledge base
Breadcrumbs

Security

We built SalesReady to run where your data is most secure by dividing responsibilities between Salesforce and Azure. Salesforce enforces authentication, authorization, and data access controls, while Azure performs compute-intensive processing within isolated Linux containers. This hybrid architecture keeps sensitive data and permissions governed by Salesforce while leveraging dedicated infrastructure for scalable, secure processing.

salesforce-with-type-logo.png Salesforce Managed Package

Coding Standards

Our development lifecycle follows Salesforce secure coding standards and leverages Lightning Web Security (LWS) to enforce runtime isolation, DOM protection, and cross-site scripting safeguards. We consistently apply CRUD, FLS, and record-level sharing controls across all data operations. Additionally, our codebase is regularly reviewed and scanned using static analysis tools to identify and remediate vulnerabilities such as SOQL injection, helping maintain a secure and high-performance environment.

OAuth 2.0

We strictly implement OAuth 2.0 flows to ensure secure access that never requires handling your raw Salesforce credentials. Every token is encrypted using tenant-scoped keys derived from your specific Salesforce Org ID, ensuring tokens can only be decrypted and used within their originating org context. This per-tenant cryptographic isolation is enforced during every API call to prevent unauthorized cross-tenant access, ensuring your data remains accessible only to your verified Salesforce instance.

Lightning Web Security (LWS)

By requiring LWS, SalesReady safely unlocks advanced LWC capabilities, such as cross-namespace component communication and the seamless use of our only third-party library. This modern architecture provides a more robust, standards-based sandbox than the older Lightning Locker, ensuring high performance while maintaining strict data isolation and protection against cross-site scripting.

Protected Storage

We leverage Protected Custom Metadata and Settings to ensure sensitive secrets are invisible to subscribing orgs, further hardening them via field-level security and platform-level encryption to prevent unauthorized access.

10018-icon-service-Azure-A.png SalesReady Integrated Web App

TLS

Our architecture enforces TLS 1.2+ across all communication channels to guarantee the confidentiality and integrity of data in motion. By configuring our Azure App Service with strict HTTPS enforcement, we eliminate insecure, plain-text connections and ensure that every interaction between our application, Salesforce, and the end-user occurs over a hardened, encrypted tunnel.

Secrets Management & Encryption

Our backend uses Azure Managed Identities to enable secret-less authentication, eliminating embedded API keys or master passwords from our source code. Sensitive credentials and tokens are protected using envelope encryption through Azure Key Vault, where data is encrypted with tenant-scoped data keys that are wrapped by hardware-backed RSA-OAEP-256 master keys. Secrets remain encrypted at rest and are decrypted only in memory during authenticated execution.

Application-Level Protection

Our application layer is built on a fortified Flask framework that enforces Cross-Site Request Forgery (CSRF) protection for all state-changing operations, ensuring every request is cryptographically validated. We mandate Secure-only session cookies to prevent browser-level data exposure and utilize a restrictive CORS policy to ensure that only authorized origins can interact with our resources. Additionally, we maintain continuous monitoring and centralized logging to detect and respond to application-level anomalies in near real time.

Compute & Container Isolation

SalesReady is deployed on dedicated Premium compute resources, providing logical isolation from other tenants and predictable performance. The application runs within Linux containers, creating an immutable runtime environment that reduces configuration drift and ensures consistent deployments. Containers are rebuilt and replaced during each release, limiting persistent state and minimizing the overall attack surface while maintaining strong workload isolation.