Security guidelinesEdit on GitHub
This document describes the guidelines for securing your customers’ and partners’ data.
The most important about password security is to not save it in plain text. Therefore, Spryker uses BCrypt based on Blowfish to hash passwords and add a random salt to each hash, preventing rainbow table attacks. To prevent dictionary and brute force attacks, you can force users to use special characters by adding validation rules to needed forms. For even higher security, use 2-factor authentication and CAPTCHA.
As HTTP is a textual protocol having no built-in encryption, passwords and customer personal data are transferred to shops in plain text. So, a good practice is to configure and implement transport layer security (TLS), which is widely known to most users as HTTPS.
In most cases, it prevents eavesdropping on traffic of users in local public networks like free Wi-Fi hotspots. Besides, it can be used to authenticate users using third-party integrations by requiring a client certificate to be trusted.
TLS configuration is configured on the webserver level. See the following configuration references for both web servers:
Forced encrypted communication
Optionally, you can force HTTPS for the Storefront, Back Office, and Glue using the
To test web server configuration, use online tools like SSL Server Test.
Session security and hijacking
- When using TLS, you can use a
securecookie flag to instruct a browser to send this cookie back to the server only via an encrypted connection. To configure it, use the
- To prevent session fixation, session identifier is refreshed on login and logout events. We recommend implementing the same behavior for other sensitive cookies if you use them in your shop.
- Make sure that your web server configuration does not cut these flags from cookie headers.
- Make sure that
*_SESSION_COOKIE_DOMAINmatches only your domain to disallow a browser to send the cookie to another domain or subdomain.
- Never send a session ID as a GET parameter of a URL, because the ID can be logged in logs or forwarded to external websites in HTTP Referer header.
Cross-site request forgery (CSRF)
CSRF forces a user to execute unwanted actions while being logged in and either click on a specially crafted link or just embed the URL into some HTML tags triggering the request automatically—for example, the
src attribute of
img. To prevent such attacks, Symfony Form provides the
csrf_protection token by default. We recommend using it in all forms.
Cross-site scripting (XSS)
Cross-site scripting is a possibility to inject malicious scripts to be executed in the browser context, for example, for a logged-in user to scrape information from the page or steal cookies. To prevent such vulnerabilities, developers should filter input and sanitize output to prevent rendering HTML or JS code from user input.
Twig template engine has autoescaping enabled by default, so make sure to not use a
raw filter. HTML should be stripped from user input.
Usually, shop operators are trusted to enter raw HTML. Because you can’t limit them in this case, we recommend restricting access to the Back Office and other administrative panels in your shop. For example, introduce a VPN, IP whitelisting, or additional authentication.
Additionally, you can set X-XSS-Protection using
Security between the Storefront and the Back Office
The Storefront uses HTTP RPC calls to communicate with the Back Office. Secure these calls by any combination of the following:
- Implement whitelisting or DMZ between the Storefront and the Back Office. If possible, make the Back Office unavailable publicly.
- When communication is happening through untrusted networks and DMZ is not possible, use TLS. This adds some latency to communication.
- Enable Back Office authorization for Storefront requests:
- Set a random value of
AuthConstants::AUTH_DEFAULT_CREDENTIALS[‘zed_request’][‘token’]for each environment.
- Optional: Change the user name used by Storefront in
Remote code execution
Avoid triggering remote code execution as follows:
- Local file inclusion: using unsanitized paths in
includestatements. To limit locations of files to be included, use the
include_pathPHP configuration option.
- Remote file inclusion: avoid using unsanitized URLs or user input in
- Unsafe deserialization. Serialized data should not be sent to the browser and should not be accepted back by the server. During deserialization of serialized data, PHP might instantiate classes mentioned in the payload and invoke some actions. Avoid this behavior or implement signature verification methods to validate this input.
- Command injection: avoid forwarding user input to
passthru, or similar functions.
SQL injections are happening when unsanitized user input is embedded into an SQL statement. Use the following mechanisms to prevent SQL injections:
- Propel to build queries and avoid plain SQL.
- Prepared statements (used by Propel by default) and typed placeholders.
- Casting incoming data to concrete data types like integer or string.
CastIdmethod in Zed controllers.
Clickjacking is when UI tweaked to force users to click on specific buttons or links. To prevent clickjacking, set correct headers in
Content-Security-Policy provided by
HeadersSecurityServiceProvider. Make sure that the headers are not deleted by webserver configuration. For more information about clickjacking, see the OWASP article.
Obsolete or outdated dependencies
To make sure that all the security updates are installed, keep Spryker and third-party modules up to date. For upgradability guidelines, see Keeping a project upgradable.
Exceptions and debug mode
Make sure that, in your production environment, the debugging mode is disabled, and exceptions are not shown.
Debug mode is configured with the following:
Remove all the demo data from the environment. A project should only use the real data that will be used after going live. Remove all the demo data that comes with Spryker, which includes demo and admin users. Demo admin users in a live shop pose a significant security risk for your project. Also, make sure to set strong passwords when creating new admin users.
To sum up, the main points to keep the data secure are the following:
- Educate: Learn and spread OWASP guidelines in your team.
- Check web server configuration and presence of security-related HTTP headers.
- Check cookie settings.
- Configure TLS.
- Secure the Back Office, do not make it public.
- Check Spryker configuration and change default authentication parameters like users and passwords.
- Keep systems and applications up to date.
- Make sure that exceptions are not shown and debug mode is disabled on production.
For submitting the form