Sage CRM should always be implemented with HTTPS when exposed to the internet. As a system that handles sensitive customer data, exposing that data over unencrypted HTTP would be a major security risk.

An additional strategy for strengthening your defences is the implementation of HTTP Response Headers.

Response Headers are instructions passed between the client (web browser) and the server, dictating how they communicate and handle various aspects of the interaction.   HTTP Response Headers can mitigate potential vulnerabilities and enhance security. 

The System Administration Guide discusses HTTP Response Headers in the "Implementation of a Secure System". https://help.sagecrm.com/on_premise/en/2023R2/Administration/Content/InstallUpgrade/SV_ServerSecurity.htm

The example HTTP Response Headers mentioned in the documentation are X-Frame-Options, X-XSS-Protection, and X-Content-Type-Options.

X-Frame-Options:

• We recommend setting the X-Frame-Options header to "SAMEORIGIN." This measure prevents Sage CRM pages from being loaded within an iframe on another domain, effectively countering clickjacking attacks. By restricting the rendering of the pages to the same origin, you create a barrier that thwarts malicious attempts to deceive users or execute unauthorized actions.

X-XSS-Protection:

• Enabling this header with a value of "1; mode=block" activates the built-in XSS protection mechanisms in modern browsers. Cross-site scripting (XSS) attacks can be particularly insidious, allowing attackers to inject malicious scripts into web pages viewed by other users. With X-XSS-Protection in place, your Sage CRM system can automatically detect and block certain types of XSS attacks, fortifying your defence against this threat.

X-Content-Type-Options:

• The X-Content-Type-Options header, set to "nosniff," is a safeguard against MIME-type sniffing attacks. By instructing browsers not to guess the content type of a response, you prevent potential exploitation of vulnerabilities arising from incorrect content type identification. 

 These headers are implemented within IIS rather than within Sage CRM.

Method

1.  Open IIS Manager.
2. Navigate to the Sage CRM Site: Expand "Sites" in the Connections pane and select the Sage CRM instance you want to configure. 
   1. The SData website which redirects IIS to Tomcat – may also need these headers.
3. Access HTTP Response Headers: Double-click "HTTP Response Headers" in the Features View.
4. Add Custom Header:
5. Click "Add" in the Actions pane.
6. Enter "X-Frame-Options" in the "Name" field.
7. Enter the desired value in the "Value" field (e.g., "SAMEORIGIN").
8. Click "OK."
9. Apply Changes: Click "Apply" in the Actions pane.

Forcing HTTPS

 If your implementation of Sage CRM is using HTTPS then you should also set the Strict-Transport-Security (HSTS) header. This header forces the browser to always use HTTPS for communication with your website, preventing Man-in-the-Middle attacks and eavesdropping.

Note: HSTS only works if your implementation of Sage CRM already has a valid HTTPS certificate installed.

Using HTTPS should be considered non-negotiable for Sage CRM as it handles sensitive customer data, especially when the system is exposed to the internet. Failing to do so puts user information at risk and can damage your organization's reputation. Implementing HTTPS for Sage CRM is a crucial step in securing your customer data and building trust with your users.