Web Server Configuration

Overview

This document serves as a guideline to harden the web server configuration with regard to running SugarCRM. Note that this is a guideline and certain settings will depend on your specific environment and setup. This guideline focuses on Apache web server as this is SugarCRM's primary supported web server. However, the recommendations in this document apply to all web servers in general.

SugarCRM .htaccess file

During installation, SugarCRM deploys an .htaccess file in SugarCRM's root folder. The content of this file may change during upgrades as well. The primary configuration directives managed by SugarCRM are focused around disabling direct access to certain directories and files. Secondly, the configuration contains specific URL rewrite rules which are required for SugarCRM.

Although this file can be used to ship most of the settings which are explained in this document to harden the web server, SugarCRM has chosen not to do so as most of them depend on the customer's setup which cannot be fully controlled by the SugarCRM application itself.

All directives which are managed by SugarCRM are placed between the following markers inside the .htaccess file:

  # BEGIN SUGARCRM RESTRICTIONS
RedirectMatch 403 .*\.log$
...
# END SUGARCRM RESTRICTIONS

Customers can add additional directives if need. Make sure to put those directives outside of the above-mentioned markers. SugarCRM can rebuild during upgrades all directives enclosed in the above markers.

Securing .htaccess

Apache allows admins to drop in .htaccess files in any given directory. When a request comes in, Apache will scan the directory recursively for any .htaccess file and apply its configuration directives. This ability is orchestrated by the AllowOverride directive which is enabled by default on most Apache configurations.

To disable this dynamic Apache configuration behavior, disable AllowOverride and make sure to copy paste the .htaccess file content as well.

  <Directory "/var/www/html">
    AllowOverride None
    # BEGIN SUGARCRM RESTRICTIONS
    RedirectMatch 403 .*\.log$
    ...
    # END SUGARCRM RESTRICTIONS
</Directory>

When choosing for this security measure, make sure to verify if any changes have happened in the .htaccess after an upgrade. Those changes need to be applied manually back in the Apache configuration to ensure SugarCRM functions properly. Disabling the .htaccess file support also has a positive impact on the performance as Apache will no longer need to scan for the presence of .htaccess files.

Although Apache does not allow to download .htaccess files, to tighten the security around .htaccess, even more, the following directives can be added:

  <Files ".ht*">
    Order deny,allow
    Deny from all
</Files>

Prevent version exposure

By default Apache web server exposes its version and OS details in most Linux-based distributions in both the HTTP response headers as well as on the default error pages. To prevent this behavior use the following configuration directives:

  ServerSignature Off
ServerTokens Prod

The exposure of the PHP version can be disabled in your php.ini file. When exposed an X-Powered-By response header will be added containing the PHP version information.

  expose_php = Off

Another option is to unset the header explicitly in the Apache configuration:

  <IfModule mod_headers.c>
    Header unset X-Powered-By 
</IfModule>

Note that unsetting the Server header is not possible using this way. The web server will always respond with a Server header containing the string "Apache". If it is desired to remove this header as well, additional modules need to be used for this (i.e. mod_security can do this).

Directory listing and index page

Make sure to configure a default index page which should only be index.php for SugarCRM. This is mostly configured but worth checking. Additional SugarCRM does not require the directory browsing support and this is recommended to be disabled. This can be accomplished by removing Options Indexes and/or completely disable the mod_autoindex module.

Optionally additional Allow/Deny directives can be used to apply access lists to certain directories. It is not recommended to add additional authentication through Apache as SugarCRM already fully manages user authentication. The Allow/Deny directives can still be used to apply any IP access list if required by the customer.

The following example secures the root directory (default configuration), disable directory browsing and an additional IP access list is applied.

  DocumentRoot "/var/www/html"

<Directory />
    AllowOverride none
    Order allow,deny
    Deny from all
</Directory>

<Directory "/var/www/html">
    DirectoryIndex index.php
    Options -Indexes
    Order deny,allow
    Allow from 10.0.0.0/8
    Deny from all
</Directory>

Additional Options directives

SugarCRM does not rely on both CGI and SSI and it is recommended to disable this functionality explicitly. Optionally the FollowSymLinks options can also be disabled depending on your directory setup.

  <Directory "/var/www/html">
    Options -ExecCGI -Includes -FollowSymLinks
</Directory>

Web server permissions

To enhance security, ensure that your web server runs under a dedicated, non-privileged user account, rather than a generic system account like nobody.

For Apache, this is typically defined in the main configuration file (e.g., httpd.conf or apache2.conf)

  User www-data
Group www-data

Ensure the configured user/group have the proper file and directory permissions for SugarCRM. See the installation/upgrade guide for more detailed instructions regarding the required permissions.

Disable unnecessary loadable modules

Apache is modular, allowing features to be added through loadable modules. To minimize the attack surface and improve performance, disable all Apache modules that are not required for your SugarCRM deployment

The following modules are commonly needed for a functional SugarCRM instance:

mod_authz_host – access control
mod_dir – directory index handling
mod_expires – client-side caching
mod_rewrite – URL rewriting (used in many SugarCRM setups)
mod_headers – response header control
mod_mime – MIME type handling
mod_alias – URL mapping

From an Apache perspective to disable a loadable module, it is sufficient to comment out the LoadModule directives. However certain Linux-based distribution has additional configuration scripts to manage the loaded Apache modules. Please refer to your Linux-based distribution for this.

Based on your setup additional Apache modules can be used. If using Apache to terminate HTTPS connections directly, enable mod_ssl.

HTTP methods

HTTP protocol uses different methods (verbs) in requests. As per RFC-7231, different request methods are defined which serve the primary source of the request semantics. The following methods are used by SugarCRM:

For new REST API:

GET
POST
PUT
DELETE
HEAD (*)
OPTIONS (*)

Legacy SOAP/REST and BWC (Backward Compatibility) endpoints:

GET
POST

(*) Currently not in use, but may be implemented in the future.

The new REST API is accessed using the URL "/rest/vxx_yy/…" where xx_yy represents the API version number. To harden the usage of the additional HTTP methods the following directives can be used for the new REST API endpoint while only allowing GET and POST on the legacy access.

  <Directory "/var/www/html">
    <IfModule mod_allowmethods.c>
        AllowMethods GET POST
    </IfModule>
</Directory>

# Allow full method set for REST API
<Location "/rest">
    <IfModule mod_allowmethods.c>
        AllowMethods GET POST PUT DELETE
    </IfModule>
</Location>

<Location "/api/rest.php">
    <IfModule mod_allowmethods.c>
        AllowMethods GET POST PUT DELETE
    </IfModule>
</Location>

Secure HTTP traffic

SugarCRM requires the usage of HTTPS transport without any exception. Depending on your setup you can terminate the secure connection on a separate endpoint (load balancer, dedicated HTTPS termination point) or directly on the web server(s). You will also need a valid private key and X.509 certificate. In most cases, the customer needs to acquire an X.509 certificate through a public certification authority of their choice. For internal deployments, this may not be necessary when a local PKI environment is available.

When terminating the secure connection directly on the Apache web server, mod_ssl is required. A dedicated VirtualHost needs to be configured on port 443 (standard HTTPS port). The following is a basic SSL/TLS configuration as a reference. More details are covered in the next paragraphs.

  <VirtualHost 1.2.3.4:443>
    SSLEngine on
    SSLCertificateFile /etc/pki/tls/certs/example.com.crt
    SSLCertificateKeyFile /etc/pki/tls/certs/example.com.key
    SSLCertificateChainFile /etc/pki/tls/certs/example_bundle.crt
    ServerName crm.example.com
</VirtualHost>

Make sure to have your server name properly configured as it should match the X.509 certificate's CommonName (or one of the SNA's, subject alternative names). More information regarding the certificate requests including the certificate chain can be obtained from your certification authority.

Ensure to redirect all non-secure HTTP (port 80) traffic to the secure virtual host.

  <VirtualHost *:80>
    Redirect "/" "https://crm.example.com/"
</VirtualHost >

Cipher suite hardening

To ensure secure communication between clients and the SugarCRM application server, strong SSL/TLS configuration is essential.

Protocol Support

Disable insecure and deprecated protocols:

  # Apache example
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

Only TLS 1.2 and TLS 1.3 should be enabled. TLS 1.3 is preferred when supported by the client.

Recommended Cipher Suites

Use modern cipher suites that support Forward Secrecy via ephemeral key exchange:

Prefer ECDHE over traditional DH.
Avoid export-grade, anonymous, and NULL ciphers.
Use strong, well-known DH parameters or elliptic curves.

For Apache + OpenSSL, example:

  SSLCipherSuite TLSv1.2+EECDH+AESGCM:TLSv1.2+EDH+AESGCM
SSLHonorCipherOrder On
SSLCompression Off
SSLSessionTickets Off

For TLS 1.3 (handled separately by OpenSSL):

  TLSCipherSuite TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Use Mozilla’s SSL Configuration Generator to generate recommended cipher suites for your environment (Apache, Nginx, etc.).

Forward Secrecy (PFS)

Forward Secrecy ensures that encrypted traffic cannot be decrypted later, even if the server's private key is compromised. This is achieved using ephemeral key exchanges (e.g., ECDHE).

Note: Some organizations may use middleboxes (WAF, IDS/IPS) that rely on TLS termination. In such cases, PFS may limit their ability to inspect traffic. Plan TLS inspection intentionally and segment PFS where needed.

Certificate pinning is generally not recommended in most server configurations due to high operational overhead. Instead, rely on public CAs, OCSP stapling, and DNS CAA records for trust management.

Public trusted root CA's

To ensure secure SSL/TLS communication, the system running SugarCRM must maintain an up-to-date set of trusted public Certificate Authorities (CAs).

Most Linux distributions manage trusted root CAs through standard package updates. For example:

Debian/Ubuntu: ca-certificates
Red Hat/CentOS: ca-certificates
SUSE: ca-certificates-mozilla

These packages typically store the trusted CA bundle in:

/etc/ssl/certs/ca-certificates.crt (Debian/Ubuntu)
/etc/pki/tls/certs/ca-bundle.crt (RHEL/CentOS)

SugarCRM uses secure HTTPS connections for licensing, heartbeat, and update services. These outbound connections rely on the system's CA bundle to verify remote server certificates.

In environments without internet access or with custom trust policies (e.g., corporate CAs), you must manually maintain and verify the CA bundle used by your system libraries (e.g., OpenSSL, curl, libcares).

Security Tip: Regularly update your CA bundle using your OS’s package manager. Outdated root certificates may cause connection failures or weaken TLS validation.

Enforce HTTPS with HSTS

SugarCRM requires all traffic to occur over HTTPS. To enforce this at the browser level and protect against downgrade attacks (e.g., SSL stripping), it is recommended to enable HTTP Strict Transport Security (HSTS).

HSTS instructs browsers to always use HTTPS for a domain and optionally its subdomains.

Example (Apache Configuration):

  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

This enforces HSTS for 1 year, includes all subdomains, and signals intent for preload.

Important Notes Before Enabling

Ensure no part of your domain or subdomains serves content over HTTP before enabling includeSubDomains and preload.
Misconfiguration can lock users out of your site if HTTPS is not properly configured across all subdomains.

HSTS Preload List

If your SugarCRM instance is publicly accessible, you may choose to submit your domain to the HSTS Preload List. This list is maintained by major browser vendors (Chrome, Firefox, Safari, Edge) and ensures clients enforce HTTPS even on first connection.

Requirements for Preload:

Must serve Strict-Transport-Security with:
- max-age ≥ 31536000 (1 year)
- includeSubDomains
- preload
Must redirect all HTTP traffic to HTTPS
Must serve HTTPS on all subdomains

Caution: Removal from the preload list is difficult and may take weeks to propagate across browsers. Only preload if you're fully committed to HTTPS across your domain.

Content Security Policy (CSP) Header

A Content Security Policy (CSP) helps mitigate cross-site scripting (XSS), clickjacking, and other content injection attacks by specifying which sources of content are allowed to load in the browser.

Most modern browsers support CSP, and it is an effective layer of protection when used correctly. However, due to SugarCRM’s extensible nature (e.g., custom scripts, dashboards, third-party plugins), care must be taken to avoid breaking functionality.

Example CSP Header (Basic):

  Header always set Content-Security-Policy "default-src 'self'; script-src 'self'"

Note: This is a minimal syntax example, not a production-ready policy. Real-world CSP implementations may require nonce values or allowances for inline scripts, dynamic content, and third-party services (e.g., maps, analytics).

Sugar also provides a Content Security Policy Administration page, allowing admins to update settings in real time (stored in the database). This page can be accessed under Admin > System > Content Security Policy Settings."

Additional security headers

Modern web applications benefit from several HTTP response headers that help mitigate common classes of attacks. Below are recommended headers for use with SugarCRM.

Prevent Clickjacking

Use either the CSP frame-ancestors directive or the legacy X-Frame-Options header to control where SugarCRM can be embedded in an <iframe>.

Preferred (modern): Content Security Policy:

  Header always set Content-Security-Policy "frame-ancestors 'self' https://trustedpartner.example.com"

Fallback (legacy): X-Frame-Options:

  Header always set X-Frame-Options "SAMEORIGIN"

Disable Content-Type Sniffing

This helps prevent browsers from interpreting files as a different MIME type, which can block certain types of "drive-by" download attacks.

  Header always set X-Content-Type-Options "nosniff"

Secure cookie settings

Ensure the following settings are applied in php.ini to ensure legacy cookies are properly protected against XSS attacks and are only transmitted over a secure HTTPS connection.

  session.cookie_httponly = 1
session.cookie_secure = 1

Additionally, the session.cookie_path can be tweaked if other applications are running on the same web server.

Security modules

Additional Apache loadable security modules exist which can optionally be installed to better protect your system from malicious requests and/or DDOS attacks. The following modules are available for Apache 2.4:

mod_security - This module adds WAF (web application firewall) capabilities to your Apache setup. In combination with the OWASP CRS (core rule set) gives you a solid starting point for a WAF implementation.
mod_evasive - This module helps to prevent (D)DOS attacks

Covering both modules in details is out of the scope of this Security Response. Refer to the module documentation for additional details. In the future, SugarCRM may publish specific settings and fine-tuning for both modules.

Additional resources

Generic Apache security tips
http://httpd.apache.org/docs/2.4/misc/security_tips.html

Online SSL/TLS tester
https://www.ssllabs.com/ssltest/analyze.html

Useful HTTP headers
https://www.owasp.org/index.php/List_of_useful_HTTP_headers