In a previous blog post, we examined how a Content Security Policy (CSP) is like good advice given to kids. The post explained the CSP mechanism in general and outlined the phases of a possible implementation project. In a short remark, the CSP topic was called "easier" for SAP S/4HANA Cloud Public Edition compared to the Private Edition. Let's now see what "easier" looks like.
The scenario here is custom theming where the theme includes a font from a remote server. We'll see why and how the system's CSP needs to be adjusted in this case.
Start: A default theme
Let's suppose we have an SAP S/4HANA Cloud Public Edition system with one of the SAP-delivered default themes. A light-blue one with a sans font. Then the upper left corner of the screen looks like this:
Change: create custom theme with remote font
Now imagine we want to have a fancy font ("Protest Revolution" – just because it's obviously different...) from a remote font provider. To get that, we create a theme designer instance on BTP and connect it to our SAP S/4HANA Cloud Private Edition system via communication scenario SAP_COM_0623 (how that's done is not the topic here – let's assume we succeeded. Relevant documentation can be found here and here).
We create a new theme in the theme designer, define a new font family, and also use a dark background. Like this:
We reference the newly defined font family in all places where we want to see it:
Disclaimer: this is for illustrational purposes only. We do not endorse remote inclusion of fonts nor do we recommend any particular provider.
Try: not quite there yet
When the theme is available in the SAP S/4HANA Cloud Public Edition system and it is selected by the user, the result looks like this:
The new background color is there, but the font certainly is not the right one.
Looking at the browser console, we see what happens: the CSP of the system blocks our custom font provider.
And if we look up the CSP reports in the "Manage Content Security Policy" app, we see a corresponding entry for the violation:
Adjust: new entry in CSP
To fix this, we add our font to the UI_RESOURCES_FONTS list in the "Manage Content Security Policy" app. In this example, we specify the path all the way to the font name and version. If we just added the host, that would have allowed any font of that particular provider – but we don't want that, we're just interested in Protest Revolution.
Try again: success!
After the CSP configuration is saved and the page is reloaded, it looks like this:
hooray! We got our dark background and the desired font.
And the browser console now doesn't complain about CSP violations anymore. That's because the server response contains our new trusted font provider in the content-security-policy header as a font-src:
Remarks
The example in this text used remote inclusion of fonts (the CSS referenced the URL of a popular provider of fonts). If we instead downloaded the front file from the provider and uploaded it into the theme designer, no changes to CSP would have been required. In that case, the font would have been served by the system itself and this is covered by the CSP directive font-src 'self' which is active in all SAP S/4HANA Cloud Public Edition systems by default.
Loading fonts from remote servers at runtime means that calls will be made from the user's browser to that remote provider. This opens the application to another party and hence increases attack surface. It also means that the user is transferring information to the third-party font provider. The privacy implications of such data transfer should be carefully evaluated before including remote fonts.
This post showed how to change the CSP in an SAP S/4HANA Cloud Public Edition system. For more on maintenance of CSPs in the Private edition, see this blog post.
- SAP Managed Tags:
