Skip to main content

Managing Content Security Policy (CSP) in IBM MAS Manage

This article explores a new system property introduced in IBM MAS 8.11.0 and Manage 8.7.0+ that enhances security but can inadvertently break Google Maps functionality within Manage. We'll delve into the root cause, provide a step-by-step solution, and offer best practices for managing Content Security Policy (CSP) effectively.

Understanding the issue

IBM MAS 8.11.0 and Manage 8.7.0 introduced the mxe.sec.header.Content_Security_Policy property, implementing CSP to safeguard against injection attacks. While beneficial, its default configuration restricts external resources, causing Google Maps and fonts to malfunction.

CSP dictates which domains can serve various content types (scripts, images, fonts) to a web page. The default value in this property blocks Google-related domains by default.

Original value

font-src 'self' data: https://1.www.s81c.com *.walkme.com;
script-src 'self' 'unsafe-inline' 'unsafe-eval' *.walkme.com;
style-src 'self' 'unsafe-inline' 'unsafe-eval' *.walkme.com;
img-src 'self' d2qhvajt3imc89.cloudfront.net data: *.walkme.com;
object-src 'self' *.walkme.com;

This configuration allows resources from:

  • The same origin as the web page ('self')
  • WalkMe analytics (*.walkme.com)
  • Data embedded directly in the code (data:)

Solution

  1. Access system properties: Navigate to the "System Properties" application within Manage.

  2. Locate the property: Search for the mxe.sec.header.Content_Security_Policy property.

  3. Edit the value: Append the following domains to the relevant directives, separated by spaces: 

    font-src https://fonts.gstatic.com
    script-src https://maps.google.com https://maps.googleapis.com
    img-src https://maps.google.com https://maps.gstatic.com https://*.googleapis.com

  4. Apply changes: Save the modifications and apply them. No system restart is required.

New Value (after adding Google domains)

font-src 'self' data: https://1.www.s81c.com *.walkme.com https://fonts.gstatic.com;
script-src 'self' 'unsafe-inline' 'unsafe-eval' *.walkme.com https://maps.google.com https://maps.googleapis.com;
style-src 'self' 'unsafe-inline' 'unsafe-eval' *.walkme.com https://fonts.googleapis.com;
img-src 'self' d2qhvajt3imc89.cloudfront.net data: .walkme.com https://maps.google.com https://maps.gstatic.com https://*.googleapis.com;
object-src 'self' *.walkme.com;

Additional considerations

  • This solution specifically addresses Google Maps and fonts. For other blocked content, analyze browser console errors using Developer Tools to identify the domain and directive to update.
  • Remember, CSP serves a crucial security purpose. Only add necessary domains to mitigate specific issues. Avoid using * wildcards excessively.

Conclusion

By understanding CSP and adjusting the system property, you can restore Google Maps functionality and font display in Manage while maintaining a secure environment. Remember to follow security best practices when managing CSP.

Resources

Labels:

Comments

Post a Comment

Popular posts from this blog

Connection to Amazon Neptune endpoint from EKS during development

This small article will describe how to connect to Amazon Neptune database endpoint from your PC during development. Amazon Neptune is a fully managed graph database service from Amazon. Due to security reasons direct connections to Neptune are not allowed, so it's impossible to attach a public IP address or load balancer to that service. Instead access is restricted to the same VPC where Neptune is set up, so applications should be deployed in the same VPC to be able to access the database. That's a great idea for Production however it makes it very difficult to develop, debug and test applications locally. The instructions below will help you to create a tunnel towards Neptune endpoint considering you use Amazon EKS - a managed Kubernetes service from Amazon. As a side note, if you don't use EKS, the same idea of creating a tunnel can be implemented using a Bastion server . In Kubernetes we'll create a dedicated proxying pod. Prerequisites. Setting up a tunnel. ...
Post a Comment
Read more

Notes on upgrade to JSF 2.1, Servlet 3.0, Spring 4.0, RichFaces 4.3

This article is devoted to an upgrade of a common JSF Spring application. Time flies and there is already Java EE 7 platform out and widely used. It's sometimes said that Spring framework has become legacy with appearance of Java EE 6. But it's out of scope of this post. Here I'm going to provide notes about the minimal changes that I found required for the upgrade of the application from JSF 1.2 to 2.1, from JSTL 1.1.2 to 1.2, from Servlet 2.4 to 3.0, from Spring 3.1.3 to 4.0.5, from RichFaces 3.3.3 to 4.3.7. It must be mentioned that the latest final RichFaces release 4.3.7 depends on JSF 2.1, JSTL 1.2 and Servlet 3.0.1 that dictated those versions. This post should not be considered as comprehensive but rather showing how I did the upgrade. See the links for more details. Jetty & Tomcat. JSTL. JSF & Facelets. Servlet. Spring framework. RichFaces. Jetty & Tomcat First, I upgraded the application to run with the latest servlet container versio...
1 comment
Read more