How Secure Is Sales Cookie?

How Secure Is Sales Cookie?

Many SaaS products claim they are secure simply because they use SSL. The reality is that a SaaS solution requires many measures to be truly secure.

Here is an overview of advanced security measures we implement to deliver world-class security. Some of those notes are fairly technical in nature and may only make sense to security experts.

Please understand that (as a security-minded organization) we will decline all requests for confidential details such as detailed network maps or source code.

User Accounts
  • All user accounts are managed via Auth0:
    • We never store or directly access your credentials because they are managed by Auth0. All we use are tokens provided by Auth0, including identities and associated authentication claims.
    • This provides advanced security and compliance with standards such as ISO27001, ISO27018, SOC 2 Type II, and more.
    • This also enables intrusion detection (ex: logins from geographically different IPs), near-instant account lockouts, etc. Bruce-force attempts are blocked after excessive attempts, and users are notified via email.
  • Passwords are subject to the following rules:
    • At least 8 characters - including at least 3 of the following 4 types of characters: a lower-case letter, an upper-case letter, a number, a special character (such as !@#$%^&*).
    • This complies with OWASP recommendations.
    • Passwords are hashed and salted.
  • Password changes require a full password reset workflow:
    • Users must prove they have access to their email account in order to change their password.
    • User email address changes are disallowed.
  • Administrators can configure their workspace with additional login restrictions:
    • Only allow logins from specific IP ranges.
    • Only allow logins from specific providers (ex: SalesForce).
    • Require logging email addresses to match a certain pattern / domain names.
  • Single Sign On (SSO) is available upon request
    • This leverages Auth0 as an SSO broker

Web Content
  • All web traffic is protected by SSL:
    • Only TLS 1.2+ is allowed.
    • The SSL certificate is rotated at least every 3 months.
  • All web pages implement a configurable automated sign out after some period of inactivity:
    • The default value is 1 hour, but is configurable by individual users.
    • Administrators can also enforce a specific timeout value across all users.
  • All web pages implement security headers to prevent vulnerabilities, including:
    • The nosniff value for header X-Content-Type-Options.
    • The sameorigin value for header X-Frame-Options.
    • The block value for header X-XSS-Protection.
    • The Content-Security-Policy header.
    • The Strict-TransportSecurity header.
    • The Access-Control-Allow-Methods header.
    • The Access-Control-Allow-Headers header.
    • The Referrer-Policy header.
  • The web application only uses one domain for all request:
    • Except for specific fonts / Javascript libraries (listed by the Content-Security-Policy header).
    • In addition, anti-forgery tokens are used and verified for all form POSTs.
    • This greatly reduces any potential for cross-site request forgery CSRF attacks.
  • All web services are implemented using Azure's Web App PAAS offering:
    • This ensures automatic deployment of the latest security patches.
    • This provides advanced security and compliance with standards such as ISO27001, SOC 1, SOC 2, and more.
  • Only two cookie are persisted:
    • Those two cookies store the user's timezone name and offset which do not grant special permissions.
    • All other cookies are session-only cookies (i.e. are destroyed when users close their browser).

SOC Type 2
You can find a copy of our Azure and Auth0 complementary controls here.

Data Storage
  • All data is stored in Microsoft Azure:
    • All workspace data is stored in Azure's SQL PAAS offering.
    • This ensures automatic deployment of the latest security patches.
    • This provides advanced security and compliance with standards such as ISO27001, SOC 1, SOC 2, and more.
    • All backups are stored in Azure storage accounts with no public access.
    • Calculation logs are stored in Azure storage accounts with no public access.
  • SQL transparent data encryption is enabled by default for additional security.
  • SQL Advanced Threat Protection is enabled for additional security.
  • Administrators can enable data retention policies to hard-delete transactions past a certain date.
  • All your data will be stored in the United States only within the Microsoft Azure platform.
  • Data is never copied to locations other than Microsoft Azure.
  • Connector credentials are stored using Azure Key Vault.

Application Security
  • Sales Cookie implements security roles such as full admin, limited admin, etc.:
    • This allows implementations to control access to various resources.
    • Specific incentive plans can be hidden from users.
  • Sales Cookie records all configuration changes in an activity log:
    • This transaction log is shown within the web application.
    • Full administrators can review and download user activity logs.
    • We log the action, timestamp, IP address, etc.
  • Employees salaries are protected at the data level:
    • Data retrieval logic prevents users other than full admins from retrieving user salary information.
    • The salary field is also visually masked in the web interface.

Source Code
  • Source code is regularly audited for potential vulnerabilities and possible threats - both manually and using automated programs.
  • Source code includes hundreds of security-related unit tests - to verify aspects such as data filtering, user authentication, role enforcement, etc.
  • Security unit and integration tests include positive, negative, fuzzing, edge, and invalid inputs.
  • Security static code analysis is performed regularly.
  • All code uses an entity framework to access the database, preventing all risks of SQL injection.
  • All code uses a library for encoding strings when generating web pages, preventing all risks of script injection.
  • All security-related code must be reviewed by an engineer with at least one security-related patent.
  • All developers must pass an extensive security training yearly.

  • All computations are performed in Azure's Web App offering:
    • This ensures automatic deployment of the latest security patches.
    • This provides advanced security and compliance with standards such as ISO27001, SOC 1, SOC 2, and more.
  • The web application provides a downloadable log for all performed computations.
  • All calculation-related data is cleared from memory as soon as the calculation completes.
  • When performing an incentive calculation, the web application takes a read-only snapshot of the plan at the time the calculation was submitted for auditing purposes.
  • When performing an incentive calculation, calculation logs are available for auditing purposes.

  • Payment logic uses tokenization to avoid storing actual credit card numbers.
  • Payment is processed using Stripe, a level 1 PCI compliance service provider.
  • Payment processing is protected by certificates.
  • Stripe Radar is used to detect potential fraud. 

  • Emails are authenticated using SPF and DKIM records in DNS.
  • Emails are delivered using MailJet, an email delivery service.
  • Emails are not encrypted when sent.
  • Emails do not include sensitive data:
    • Instead, links are sent, which require authentication to access.
  • In some cases, we may send emails on your behalf to your payees:
    • The sender is set to <account>
    • The display name is set to your email address.
    • The reply-to field is set to your email address.
    • This is used to identify who requested that emails be sent.
    • You can disable this behavior in security settings.

  • Encryption operations are delegated to third-parties (ex: Auth0, SQL Azure, etc.).
  • HMACs used to verify the origin of certain data use SHA-256.
    • We use a truly random initialization vector as per NIST recommendations.
    • Keys are rotated every 3 months and stored in Azure Vault.

Data Transfer
  • All data transfers are protected by HTTPS / SSL.
  • All data transfers are logged.
  • We use SQL Azure dynamic data masking to protect emails, user names, amounts for non-privileged SQL accounts.
  • While data may occasionally be transferred outside of the United States (because of the way the Internet works, or because you are not located in the United States), it will remain encrypted via SSL until its destination is reached.

Data Usage Policy
  • We will never share or sell your data.
  • We will never share or sell an aggregate or transformed version of your data.
  • Your data will never be shared with or sold to any other third-party.
  • We will never use your data for purposes other than calculating commissions and providing corresponding reporting capabilities to you.
  • In the unlikely event of a data breach, we will disclose all relevant information to all affected parties within at most 72 hours.
  • Upon request, we will delete all your data (excluding billing information).
  • For more details, please review our privacy policy.

Data Access Policy
  • Access to your data is only granted to our employees on a need-to-know basis such as:
    • Helping you configure incentive plans by examining your data (pre-sales).
    • Helping you verify commissions by examining your data (technical support).
    • Ensuring compatibility of a new product feature with your data (engineering).
  • Access is protected by 2-factor authentication.
  • Our employees must pass an extensive background check before being granted access.
  • Our employees must complete a security training every calendar year.

Data Processing Agreement
  • We may execute a data processing agreement (link) with specific customers.
  • This binding agreement describes and limits usage of your data.

VirusTotal Scan
We maintain a 100% reputation for VirusTotal scans.

Security Report
  • We may share a detailed penetration security report with specific customers under NDA.
  • This report shows the result of executing hundreds of security tests and online scans.

    • Related Articles

    • Getting Started With Sales Cookie - Payees

      About This Guide This guide is designed to help you get started with Sales Cookie as a payee. For the admin starter guide, click here. This guide does NOT cover the many advanced options or capabilities found within Sales Cookie. However, we will ...
    • Getting Started With Sales Cookie - Admins

      About This Guide This guide is designed to help you get started as a Sales Cookie administrator. We assume that we've already configured one or more incentive plans for you. Looking for a starter guide for your payees instead? Click here. This guide ...
    • How Can I Import Sales Cookie Data Into Google Sheets?

      Sales Cookie offer a rich entity schema and APIs. Some solutions such as Power BI, Tableau, or Excel natively understand structured data. They also offer native support for JSON Web APIs such as OData. However, Google Sheets does not offer the same ...
    • How Can I Embed Web Content Within Sales Cookie?

      You can create and publish announcements to personal incentive dashboards. However, sometimes you already have some existing content you want to show within Sales Cookie. This could be: Sales resources Sales training guides Various documents (ex: ...
    • How Can I Embed Power BI Reports Into Sales Cookie?

      Ready to share exciting commission reports with incredible visuals with other Sales Cookie administrators or payees? This article explains how you can embed Power BI reports within Sales Cookie. This article assume you have already created a Power BI ...