Moesif recognized in the 2024 Gartner® Hype Cycle™ for APIs in the API Observability, API Monitoring, and API Portals categories.

Security Program at Moesif

Moesif has implemented robust security procedures throughout the platform and organization. Moesif maintains an active SOC 2 Type 2 attestation available in the Moesif Trust Center and is a big believer in zero-knowledge and multi-layer security for protection of your data. The founding team are engineers that have worked on CPU architecture and sensitive microcode patches at Intel to handling sensitive payment data at Microsoft for XBox Live and MSN.

Moesif also acknowledges that no environment can guarantee absolute security. Moesif recommends either masking sensitive data such as ePHI (electronic Protected Health Information) or PCI DSS (Payment Card Industry Data Security Standard) using our SDKs mask function or leveraging Moesif's client-side encryption feature to meet compliance requirements for sensitive data like financial and healthcare.

API Tokens

All Collector API tokens for data ingestion are write only tokens that are signed using HMAC SHA-256. Publishable Application Ids are safe to put in untrusted apps such as javascript running in a browser. Secret Application Ids should not be placed in untrusted apps.

Management API tokens are also signed using the HMAC SHA-256 algorithm and can be limited to specific resource scopes and can have a specified token expiration date. Please follow the principle of least privilege and add only the minimum scopes that you need for the access token. If you need a short lived token to perform certain maintenance tasks, create a token that expires in hours or days.

Moesif creates unique keys for each use case. Those keys are not reused for unrelated purposes.

SSL

The Collection API, Management API, and moesif.com web portal all use SSL using Transport Layer Security (TLS) 1.2 or higher and the latest SHA-256 algorithm for encrypting all network traffic. Moesif's SSL implementation received an "A+" on Qualsys' SSL Labs. All of our open source SDKs and agents are configured to use HTTPS. The moesif.com domain also has HSTS enabled.

Encryption at Rest

Moesif encrypts customer data while at rest of both production data and backups using 256-bit AES encryption with encryption keys stored in Azure Key Vault. Data is stored only in the cloud in ISO/IEC 27001 and ISO/IEC 27017 compliant data centers in Microsoft Azure which further provides fault-tolerance and strong access control to physical machines. However, we don't simply rely on Azure for security and implement our own access control.

To keep sensitive data private to your organization, Moesif provides client-side encryption via the secure proxy appliance for enterprise customers which enables zero-knowledge security with customer-managed encryption key.

Backups

Snapshots of customer data are made multiple times per day and redundantly archived in Azure Blob Storage geographically separate from live data. These backups are regularly tested. Moesif also backs up all streaming data via continuous replication to ensure a Recovery Point Objective (RPO) of almost zero.

Data Storage Location

Moesif customer data at rest currently resides in the United States of America.

Server Infrastructure

The Moesif platform runs on hardened hosts with tightened security groups, role-based access controls, and isolated virtual networks on the Microsoft Azure platform. A business reason and approval must exist before employees or management is granted to a portion of the production infrastructure. Development environments do not have access to production data stores or virtual networks. Employees engaged in customer service can access a web portal with access to customer data similar in structure to the Moesif end user portal. Access to this system is logged.

Moesif infrastructure uses Azure Active Directory for RBAC with 2FA required. Moesif disables SSH authentication via passwords for production Linux machines.

User Authentication

Moesif offers Single Sign-On (i.e SAML and Okta) and role-based authorization control for enterprise plans. Moesif also offers the ability to enforce a specific social identity provider (i.e. Google or GitHub) for all paid plans. Moesif provides guidance for new users when choosing a password and will alert your team members when a reused password was leaked even on other websites. Moesif uses Auth0 service for user authentication which never stores passwords in plaintext and ensures all passwords are hashed and salted via bcrypt. More information on Auth0's security can be found here

Monitoring

Moesif continuously monitors access to its infrastructure. Automated vulnerability scans and penetration testing are regularly performed.

Workstations

Moesif has security policies and tooling in place for company workstations which enforces Full Disk Encryption and auto lock when left unattended. Bring Your Own Devices are protected with Mobile Device Management (MDM).

Email

To prevent phishing scams or other cyber attacks, Moesif has deployed DMARC which builds on existing mechanisms like DKIM and SPF to detect and prevent email spoofing. Moesif also keeps logs on such spoofing attempts.

Vendor Passwords

Moesif's critical accounts (AWS, Azure, Google, GitHub, Chargebee, Slack, etc) enforce mandatory 2FA for all employees or Single Sign-On when available. If allowed by a service, Moesif makes SMS based 2FA disabled as SMS is considered insecure for 2FA. Moesif employees are encouraged to use the company provided password manager and never share passwords across accounts.

Payment Information

Credit card and payment information is held by our payment providers, Stripe and Chargebee. Moesif does not store any payment information. If you signed up via a partnership program that integrates billing such as Heroku or AWS, your payment information may be held at that partner instead of our own payment providers.

Reporting an Issue

If you believe you’ve discovered a bug in Moesif’s security, please get in touch at security@moesif.com and we will get back to you within 72 hours, and usually earlier. You will find our PGP key in case you need to encrypt communications with us. We request that you not publicly disclose the issue until we have had a chance to address it.

Please include:

A summary of the problem
A severity rating of 1 - 5 (1 being least severe, 5 being most ie. you can easily hijack, impersonate or access any other account or data)
A PoC or breakdown of how to replicate the issue.
The operating system name and version as well as the web browsers name and version that you used to replicate the issue

PGP

If you plan to include tokens or any sensitive information, please kindly use PGP to encrypt your email.

Download PGP Key

Non-qualifying vulnerabilities

We will unlikely review and respond to the submissions of the following types:

"Scanner output" or scanner-generated reports
"Advisory" or "Informational" reports that do not include any Moesif-specific testing or context
Denial of Service attacks
Brute Force attacks
CSV Injection
Security issues in apps or services that are not operated by Moesif (including third-party services and websites operating on Moesif’s subdomains)
Vulnerabilities requiring physical access to the victim's unlocked device
Spam or Social Engineering techniques
Issues relating to Password Policy
Non-sensitive information disclosure (such as product version, path, etc.)
CSRF in actions that are non-significant (e.g., logout) or do not require authentication (or a session) to exploit
Clickjacking on pre-authenticated pages, or the non-existence of X-Frame-Options, or other non-exploitable clickjacking issues (An exploitable clickjacking vulnerability requires a) a frame-able page that is b) used by an authenticated user and c) which has a state-changing action on it vulnerable to clickjacking/frame re-dressing)
Self-XSS without demonstrating a real impact for users
Lack of security mechanism or inconsistency with best practices without demonstrating a real security impact (e.g., lack of security headers)
SSL/TLS issues from scans or known best practice issues
Vulnerabilities that only affect users of outdated or unpatched browsers
Insecure cookie settings for non-sensitive cookies
Bugs that do not pose any security risk
Publicly-released bugs in internet software within 3 days of their disclosure