OWASP Top Ten - 2021

One of the most critical missions of Casewhere is to provide applications with a strong security foundation to protect their data and users. We adopt OWASP Top Ten as one of our standard security guidelines and constantly evaluate Casewhere against these security threats. We also understand that OWASP Top Ten is just a starting point.

A01 – Broken Access Control

Except for public resources, Casewhere denies all access by default. Access control in Casewhere can be done at multiple layers. Casewhere embraces the principle of least privilege and the defense-in-depth approach by enabling the ability to assign access rules to all types of resources:

Worker site: This is the highest level of protection. Rules assigned to a worker site are always enforced when users access a resource in the worker site
Page: To protect the page itself, including widgets and workflow actions inside the page
Widget: To protect the widget itself, including widget data and workflow actions inside the widget
Widget action: To protect the triggered workflow
Data source: To protect all data queries on the data sources
Data class: To protect read/write access to data at the field level
Custom access control: It's always possible to implement custom access control logic in data filters and workflows

Last but not least, Casewhere logs all unauthorized access attempts by default.

A02 – Cryptographic Failures

First of all, all Casewhere deployments enforce HTTPS by default. Secondly, data at rest will be protected by disk encryption. If the customer can adopt MongoDB Enterprise, there will be an extra encryption layer at rest. At the application level, Casewhere employs Microsoft Data Protection API with strong encryption algorithms; encryption keys are also encrypted at rest and rotated frequently. We have very strict policies to store the key-encryption key (i.e., the key to encrypt the encryption keys). It's possible in Casewhere to enable field-level encryption for sensitive data such as credit card numbers, social security numbers, etc.

A03 – Injection

Casewhere applies many techniques to prevent injection threats:

All data queries are parameterized
User-supplied data is always validated against the data schema
Hostile APIs such as executing scripts on the server side are turned off by default

A04 – Insecure Design

Security is a feature in Casewhere, as our top mission is to provide developers with a solid security toolbox to develop secure applications. Security requirements go side by side with business requirements in the whole development lifecycle, from the early feature analysis, functional designing with threat modeling, and data modeling to implementation, testing, and even documentation. The development process of Casewhere embraces secure-by-design principles:

Minimize attack surface area: Every time a developer adds a feature, they increase the risk of a security vulnerability
Establish secure defaults: The application must be secure by default. That means a new user must take steps to obtain higher privileges and remove additional security measures
The principle of least privilege: A user should have the minimum set of privileges required to perform a specific task
The principle of defence in depth: Multiple security controls that approach risks in different ways are the best option for securing an application
Fail securely: Applications should fail in a secure way. Failure should not give the user additional privileges, and it should not show the user sensitive information like database queries or logs
Zero trust: The application should always check the validity of data sent by users or third-party services
Avoid security by obscurity: If an application requires its administration URL to be hidden so it can remain secure, then it is not secure at all. There should be sufficient security controls in place to keep your application safe without hiding core functionality or source code.
Keep security simple: Developers should avoid using overly sophisticated architecture when developing security controls for their applications. Complex mechanisms can increase the risk of errors.

A05 – Security Misconfiguration

Casewhere is an application platform, so it's a top priority to provide documents and guidelines for deploying and configuring the platform most securely.

Besides guidelines and documents, Casewhere's import/export feature enables quickly migrating configuration across environments with different credentials used in each environment. This process should minimize the effort required to set up a new secure environment.

It's best practice to have a task to review and update the configurations appropriate to all security notes and updates. Many of these can be done automatically by using the Casewhere automation test feature. For example, you can write tests to verify if unnecessary features/endpoints in Casewhere are turned off and if the setting values have the expected value.

Finally, it's still the developer's responsibility to use Casewhere securely and also improve their awareness of different security aspects.

A06 – Vulnerable and Outdated Components

Casewhere has an integration to continuously monitor for vulnerabilities in the components. Our release model facilitates quick response to critical security issues while also providing periodical security patches.

A07 – Identification and Authentication Failures

Casewhere does not have built-in authentication, but the platform can integrate with almost all well-known IdPs such as Safewhere Identify, AD, AAD, which support all kinds of best practices for identification and authentication.

A08 – Software and Data Integrity Failures

To mitigate the threats, the Casewhere development enforces the following rules when using third-party components:

Libraries and dependencies are from trusted repositories
Review the code of third-party major components and integrations
Integration in CI/CD pipelines to continuously monitor for vulnerabilities in the components

The platform also provides developers with essential APIs and components for protecting and verifying data integrity.

A09 – Security Logging and Monitoring Failures

Logging is the area Casewhere really puts its heart and soul into. Below are the highlights:

Our Event Sourcing architecture ensures that all data changes are recorded as events in the database. It's always possible to tell who did what and when
The Casewhere auditing tracks both read/write accesses with high flexibility for customization. All unauthorized accesses are logged by default
Logs and events are stored in a consistent, readable format
Logs and events databases are managed separately with stricter policies. The applications can only write logs and have no access to modify log entries once they are stored in the database
The platform provides APIs to enable custom logging when needed
Casewhere can write logs using different storage technologies (plug-and-play). The platform also provides components for exporting logs to other storage, as we understand that storing logs locally alone is not a good practice

Casewhere monitoring functionality makes it possible to:

Monitor failed workflows
Subscribe to failure events to trigger custom workflows. For example, you can implement a workflow to send an alert email when a payment transaction fails to execute. You can also implement a workflow to send the events to analytics platforms if your system demands a more sophisticated alert policy
Configure rules to automatically retry failed workflows

A10 – Server-Side Request Forgery (SSRF)

Casewhere strictly adheres to the zero-trust principle and validates all data sent from users or external services. The platform does not have APIs that fetch remote resources based on user-supplied URLs. However, the risk is still high for applications on top of Casewhere if developers are not aware of this threat, especially when implementing RESTful APIs using web triggers. To mitigate the threat, we encourage Casewhere application developers to:

Sanitize and validate all client-supplied input data
Enforce the URL schema, port, and destination with a positive allow list. Do not mitigate SSRF via the use of a deny list or regular expression. Attackers have payload lists, tools, and skills to bypass deny lists
Do not send raw responses to clients