Magento Security Checklist
This is a community sourced checklist of security measures to take before launching your store. Think of it as a pre-flight checklist so you don't forget something important because you've been in a headlong rush for the last few months to get all the features of your eCommerce site built.
This checklist will apply to only Magento 2.x versions.
- Are all inputs validated on the server side?
- (TODO: Link to validation tutorial)
- Are you sanitizing all inputs also? (eg: casting to integers if a number is expected?)
- Are you correctly protecting your code against PHP string comparison vulnerabilities? (eg. == vs ===)
- Are you using Magento built in
form_keyvalidation on all custom forms?
- (TODO: Link for more info on CSRF Anti-forgery tokens)
- Are you properly escaping all output to screen using
escapeJs()and similar functions?
- Are you setting
Secureflag on any custom cookies?
- Are you using the
Magento\Config\Model\Config\Backend\Encryptedbackend model for sensitive API data to be stored in the DB? eg: payment gateway keys.
- Are you using any dynamic code execution functions like
shell_execor backticks (``)?
- Are you building MySQL queries properly and not using direct queries?
- Are all sensitive or system specific settings treated as sensitive configuration?
- Are you adhering to the Magento Technical Guidelines when developing custom code?
- Are you sanitizing/ filtering user inputs and dynamic data against malicious code to prevent cross-site scripting (XSS)?
Extension security checklist
- Do you have the latest version of all the extensions being used on the site?
- Are all your extensions using Magento ACL properly to limit the scope of users?
- (TODO: ACL tutorial)
- Did you perform a security audit on 3rd party extensions used on the store?
- At the very least execute Extension Code Review against Magento Coding Standards
- Use a tool that reports the usage of dependencies with known security vulnerabilities
- Review if Passwords/API Credentials or other Sensitive Data stored by 3rd Party Extension are not save in Database using
- (TODO: Link to more sample tools to help perform security audit on extensions)
- Review the need of using
Magento_VersionModules in Production Environment (consider to
Disablethose CORE Modules or at the very least restrict access to
- Are you updating the 3rd party extensions on a regular basis?
Magento Admin settings
- Are you using a custom Magento Admin URL?
- Is the secret key added to admin URLs?
- Is access to your Admin URL IP whitelisted or protected via VPN?
- If you can't make the Admin URL private, are you using CAPTCHA/ reCAPTCHA for admin login form?
- Is the admin session lifetime set to a reasonable configuration (1-2hrs)?
- Are you reinforcing admin password renewal at least every 3 months?
- Are you disabling the admin account sharing?
- Are you limiting the failed admin login attempts to a reasonable number of times (eg 3)?
- Confirm that Web -> Default Cookie Settings -> Use HTTP Only is not disabled?
- Are you using 2FA for your admin login?
- Are there any old/unused admin users which were created for testing or development that should be removed?
- Are you using CAPTCHA/ reCAPTCHA for customer facing web forms?
- Is your site logging information in a format that is easily reviewed by your team?
- Is your site logging any potentially sensitive information?
- Is you TLS certificate properly installed and your OpenSSL configuration set to high standards?
- Do you have notifications turned on for filesystem integrity?
- Disable Server Signature:
- Set secure PHP settings in
- Minimize the number of PHP modules you have installed. Remove any not needed by Magento.
- Disable PHP version exposure:
expose_php = Off
- Disable Script Name exposure for
mail.add_x_header = Off
- Disable errors:
display_errors = Off
- Set httponly flag as default for cookies:
session.cookie_httpsonly = On
- Set secure flag as default for cookies:
session.cookie_secure = On
- Disable remote file inclusion:
allow_url_fopen = Offand
allow_url_include = Off
upload_tmp_dirto appropriate directories for you distro/installation
- Are there any (development) files or database dumps lying around in the production document root that are not intended for public usage (for example info.php, phpinfo.php, dbdump.sql.gz)?
- Does an unnecessary
.gitignorefile exist in your production filesystem?
- Are any required files for server operation readable publicly? eg:
- Do all your folders in your docroot have the appropriate permissions set? (for example var/logs, /var/report, install)?
- Have you analyzed your HTTP response headers for problems?
- Unless you have specific requirements for them have you limited all requests to
- Are you disabling the directory paths indexing/ listing?
- Can you set your Magento php files installation as read-only?
- Do you have a process for matching the production server files with a known good state?
- TODO: need to add mod_security information
- Is the webserver & Magento’s app/etc/env.php configured to use /pub as document root?
- Is /media/ accesible?
- Are there any executable files inside /media/?
- Are you using up-to-date services (where compatibility allows it)?
- Are you disabling or returning 404 the requests to pages with unused forms?
- Are you granting server access only by SSH connection and usage of individual users with individual keys?
- Are you providing access only to the people who actually need it, and only to the resources they need?
- Are you documenting all SSH keys and update them as team members change the keys or are added/ removed to/ from the team?
- Are you reviewing all access by project team members and staff periodically (at least every 3 months)?
- Are you disabling SSH access for root user?
- Is the default SSH port changed from 22 to something else (eg 2233)?
- Is SSH password authentication disabled?
- Do you have an Incident Response Plan implemented and tested (mock scenario)?
- Do you have a person with regular scheduled time to review log messages for suspicious behaviour?
- What is your process for dealing with IP address that are attempted to directory bruteforcing?
- Do you have automated offsite backups for your site enabled?
- Are these backups encrypted and on a non-public location?
- Are these backups treated with the same level of security as your existing code?
Secure Development processes
- Do you have a process for sanitizing production data for developers?
- Do you have a list of developers/support staff with full access to your production systems and a process for accessing them?
- Are you blocking access to testing machines and use a whitelist for IPs that really need to access these resources?
- Are you keeping a catalog of all IPs - who and why they have access over HTTP to these machines and periodically check if they still need the access?
- Are you using environment variables to overwrite any production URL for payment processors, 3rd party API integrations or other sensitive configurations which you might overlook when updating the testing machine database with a backup from production?
- Does your site contain the latest security patches and updates?
- Are you applying the security patches' new standards/ changes to the custom code developed so far? Without this, the patch can be useless (the system is as strong as its weakest link).
- Do you have a person with a subscription to security notices from Magento security blog for urgent patches/updates?
- Do you have a recurring reminder to execute regularly review validity of existing Admin accounts (including the allocated resources)?
- Recommended monthly
- Are you reviewing on a regular basis (at least every 3 months) the existing API integrations and the allocated resources?
External security concerns
- If you are using a Web Application Firewall (WAF) does it provide virtual patching and how do you keep it up to date?
- Magento User Guide's Security Best Practices