Developer Network
Contact
Pricing

Content Security Policy in Mendix: Implementation Guide

Introduction

This week, I ran a poll asking how familiar Mendix developers are with Content Security Policy implementation. The results revealed interesting insights:

How familiar are you with implementing Content Security Policy (CSP) in Mendix applications?

  • Expert: Custom implementations – 25%
  • Intermediate: Basic configs – 38%
  • Aware but never implemented – 25%
  • What’s CSP? – 13%

While it’s encouraging that 63% have some implementation experience, a significant portion of Mendix developers could benefit from more knowledge in this critical security area.

In Tuesday’s carousel, we covered CSP fundamentals and why this security layer is critical for Mendix applications. Today, I’ll provide a detailed implementation guide that security-conscious Mendix developers can use to protect their applications from XSS attacks and other content injection vulnerabilities.

Why Mendix Applications Need Content Security Policy

Before diving into implementation specifics, let’s briefly revisit why CSP is particularly important for Mendix applications:

  • Custom Widgets and JavaScript Actions: Mendix’s extensibility through custom widgets and JavaScript actions creates potential entry points for XSS attacks if not properly secured.
  • Marketplace Modules: Third-party modules from the Marketplace may introduce scripts from various sources that need to be explicitly permitted.
  • External Integrations: Many enterprise Mendix applications integrate with external systems, requiring careful control of network connections.
  • User-Generated Content: Applications that allow users to input HTML or upload content need robust security boundaries.

Without CSP, these areas become potential security vulnerabilities that can compromise your Mendix application and its data.

Prepping the Mendix Application to Support Strict CSP

In order to be able to use the strictest setting of a CSP a Mendix app requires some updates. Follow this Mendix Doc guideline for app setup.

CSP Implementation Strategies for Mendix

Strategy 1: Using Mendix Runtime Configuration for HTTP Headers

The most straightforward approach for implementing CSP in Mendix applications is using the built-in HTTP headers configuration in Mendix Environments:

  1. Navigate to the Environment Details in the Mendix Developer Portal for your application.
  2. Access the Network tab where you can manage custom HTTP headers.
  3. Add a new header with the name Content-Security-Policy and your desired policy as the value:

—- CODE START —-
default-src 'self';
script-src 'self' https://trusted-cdn.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data:;
—- CODE END —-

  1. Save your configuration and restart the environment to apply the new headers.

This approach allows you to implement CSP without any custom code or modules, leveraging the platform’s built-in capabilities.

Strategy 2: Testing Before Production Implementation

Since Mendix runtime configuration doesn’t support the Content-Security-Policy-Report-Only header, you’ll need an alternative approach for testing:

  • Use a sandbox environment where you can safely implement and test your CSP policy.
  • Start with a permissive policy that includes all resources your application currently uses, then gradually restrict it as you verify functionality.
  • Monitor browser’s dev tools console to track CSP violations.
  • Methodically test all application features to identify resources that need to be included in your policy.
  • Once verified, apply the refined policy to your production environment using the runtime configuration.

Strategy 3: Implementing CSP in Local Mendix Studio Pro Environment

When developing applications in Mendix Studio Pro, testing your CSP implementation locally before deploying to cloud environments is crucial. Follow the setup steps in the Mendix Doc referenced above and then:

  • Run your application locally from Studio Pro to test the CSP implementation.
  • Check browser developer tools to verify the CSP is being applied and to identify any violations in the Console tab.

Strategy 4: Using Browser Extension for Testing

For quick testing without modifying your application code:

  • Install a CSP browser extension: For Chrome: “Content Security Policy Evaluator” For Firefox: “Laboratory by Mozilla”
  • Configure the extension with your desired CSP policy.
  • Run your Mendix application locally and use the extension to apply and test different CSP configurations.
  • Monitor the Console in developer tools to see violations.
  • Refine your policy based on the violations before implementing it in your application.

Troubleshooting Local CSP Implementation

When testing CSP locally, you might encounter these common issues:

  • Marketplace Widgets Compatibility: Many marketplace widgets use inline scripts or styles. Test each widget carefully and adjust your CSP accordingly.
  • Local Resource Loading: In development environments, ensure your CSP allows loading resources from localhost and any local testing URLs.
  • Inconsistent Behavior: CSP behavior might differ between local development and cloud deployment. Always verify your policy in all environments.

Moving from Development to Production

After testing your CSP implementation locally:

  • Remove the code added in head tag from html after finishing testing locally.
  • Gradually remove unsafe directives like 'unsafe-inline' and 'unsafe-eval' by finding alternative implementations.
  • Document all required sources for each directive based on your testing.
  • Create environment-specific policies for development, testing, and production.
  • Implement the refined policy in your cloud environments using the Runtime Configuration HTTP headers as described earlier.

Special Considerations for Mendix Applications

Handling Atlas UI and Theming

Atlas UI components often use inline styles which can be problematic with strict CSP. You have several options:

  • Allow 'unsafe-inline' for styles initially while moving toward a more secure configuration.
  • Modify Atlas UI components to use external stylesheets.
  • Use calculated hashes for essential inline styles that cannot be externalized.

Securing Mendix Widgets

Custom and marketplace widgets present particular challenges for CSP:

  • Audit your widgets for inline script usage or event handlers.
  • Update widget source code to use more secure patterns when possible.
  • Use CSP nonces for widgets that absolutely require inline scripting.

Handling External API Calls

For Mendix applications that make AJAX calls to external APIs:

  • Explicitly whitelist API domains in your connect-src directive.
  • Consider using a proxy microflow for APIs that cannot be directly whitelisted.
  • Implement sub-resource integrity for external scripts when possible.

Common Pitfalls and Solutions

Pitfall 1: Over-Permissive Policies

Many implementations start with overly permissive directives like script-src * which largely defeats the purpose of CSP.

Solution: Begin strict and only add exceptions based on actual needs identified through testing.

Pitfall 2: Relying on ‘unsafe-inline’

The 'unsafe-inline' directive for script-src essentially negates much of CSP’s XSS protection.

Solution: Use nonces or hashes instead of 'unsafe-inline' wherever possible, especially for scripts.

Pitfall 3: Neglecting frame-ancestors

Many developers focus on script sources but forget to restrict which sites can embed their application.

Solution: Always include frame-ancestors in your policy to prevent clickjacking attacks.

Implementing a Comprehensive CSP Through Iterations

Achieving a truly robust CSP implementation in a Mendix application is an iterative process:

  • Initial Deployment: Start with a baseline policy in a test environment.
  • Data Collection Phase: Gather violation data during comprehensive testing.
  • First Refinement: Update the policy based on legitimate needs.
  • Targeted Testing: Have users test specific functionality to ensure everything works.
  • Enforcement Launch: Deploy to production with careful monitoring.
  • Continuous Improvement: Regularly review violations and tighten the policy.

Testing Your CSP Implementation

To verify your CSP implementation:

  • Use browser developer tools to check if CSP headers are being correctly sent.
  • Attempt intentional violations in a test environment to confirm blocking works.
  • Validate your policy by using various CSP evaluation tools.
  • Include CSP testing in your application’s security testing procedures.

Conclusion

Implementing a robust Content Security Policy in Mendix applications requires careful planning and iterative refinement, but the security benefits are substantial.

By following the strategies outlined in this guide, you can protect your Mendix applications from a wide range of content injection attacks.

For organizations looking to elevate their Mendix application security with enterprise-grade CSP implementation, Golden Earth provides specialized consulting services. Our team of senior Mendix developers can help you design and implement robust security strategies tailored to your specific business requirements.

Stay tuned for more security content, and don’t forget to join us for our Capture the Flag security event in Montreal this October, where you can test your Mendix security skills against real-world challenges!