The Security Baseline for Magento 2

81 rules to keep your magento store secure.

C01 — File & Folder Permissions

No chmod 777

Magento project files and directories must never be world-writable using chmod 777. Overly permissive permissions allow attackers or rogue processes to modify code and configuration. Always apply least-privilege settings, restricting write access to only the system user that runs Magento.

Go to rule →

Secure env.php permissions

The app/etc/env.php file contains sensitive credentials, including database and encryption keys. It should be restricted to mode 640 or stricter, owned by the correct application user and group. Insecure permissions may expose secrets to unauthorized local users or processes.

Go to rule →

Webroot hygiene

The webroot (pub/) must be free of leftover developer artifacts such as .git, .env, or backup files. These files often reveal credentials, configuration details, or source code. Attackers frequently probe for them as an easy first step to compromise.

Go to rule →

Restrict code dirs not writable

Core application directories like app/, vendor/, and lib/ must be read-only for the web server user. If writable, an attacker exploiting Magento could plant malicious PHP code directly into dependencies. Enforcing read-only integrity helps prevent supply-chain style compromises.

Go to rule →

No directory listing

Public web directories should not allow automatic directory indexing. Directory listing can expose file names, configuration fragments, and sensitive assets. Ensure the web server (Nginx/Apache) is configured to return 403/404 for requests without index files to reduce information leakage.

Go to rule →

C02 — Admin Hardening

Non-default admin path

The default /admin path is predictable and targeted by bots and automated scanners. Configuring a custom backend route significantly reduces attack surface. It forces attackers to guess the admin location, improving security against brute-force and credential stuffing attempts.

Go to rule →

Admin 2FA enabled

Two-Factor Authentication (2FA) is required to secure administrative logins against stolen or weak credentials. Enabling Magento_TwoFactorAuth enforces a second verification step, making it far harder for attackers to hijack accounts even if passwords are compromised.

Go to rule →

Strong password policy

Administrative accounts must use passwords with minimum length and complexity requirements. Enforcing rules for length, mixed characters, and rotation reduces the risk of brute-force attacks. Weak policies leave accounts vulnerable to dictionary or credential stuffing techniques.

Go to rule →

Session timeout ≤ 900s

Idle admin sessions should expire within 15 minutes to limit the window of abuse. Long session lifetimes make it easier for hijacked cookies or unattended terminals to be exploited. A strict timeout reduces exposure in case of compromise.

Go to rule →

Limit admin exposure

The admin route should not be publicly discoverable or exposed unnecessarily. Blocking default redirects, disabling /admin fallbacks, and restricting access with firewalls or IP allow-lists reduce discovery by attackers and automated scans.

Go to rule →

Login rate-limit

Implement rate-limiting or CAPTCHA to prevent unlimited login attempts on the admin panel. Brute-force and credential stuffing are common attack vectors. Throttling login attempts helps slow automated attacks and improves defense-in-depth when combined with strong credentials.

Go to rule →

C03 — Secure Coding Practices

No raw SQL queries

Directly concatenating variables into raw SQL queries introduces SQL injection risks. Magento provides database abstraction layers and bound parameters that must be used. Detecting and avoiding raw SQL ensures input is sanitized, protecting against data theft or manipulation.

Go to rule →

Template output escaping

Values printed in PHTML templates must be properly escaped using $block->escapeHtml(), escapeHtmlAttr(), or similar functions. Without output escaping, user-controlled data may trigger cross-site scripting (XSS). Escaping prevents malicious scripts from executing in the browser context.

Go to rule →

Avoid superglobals

Using PHP superglobals like $_GET or $_POST directly bypasses Magento’s filtering and validation mechanisms. Developers should rely on Magento’s request API or input filters. Superglobals increase the attack surface for injection and cross-site scripting if not sanitized properly.

Go to rule →

CSRF protection

All form submissions and POST requests must include Magento’s built-in form key validation. Without Cross-Site Request Forgery (CSRF) tokens, attackers can trick logged-in users into performing unintended actions. Enforcing CSRF checks protects critical workflows like checkout or admin actions.

Go to rule →

SSRF safeguards

External HTTP requests must restrict target hosts and validate URLs. Without safeguards, attackers can abuse Server-Side Request Forgery (SSRF) to reach internal services or metadata endpoints. Implement allow-lists, strict protocols, and timeouts to reduce this risk.

Go to rule →

Deserialization safety

PHP’s unserialize() can lead to arbitrary code execution if user-controlled input is deserialized. Use JSON or Magento’s safe serializers instead. Any unavoidable use of unserialize must enforce allowed class whitelists to prevent gadget chains and object injection.

Go to rule →

Command injection guards

Dangerous functions like exec(), shell_exec(), or system() must never execute user-controlled input. Attackers may inject arbitrary shell commands. If shell usage is unavoidable, inputs must be sanitized against strict allow-lists. Safer alternatives are preferred wherever possible.

Go to rule →

No unsafe eval/dynamic code

Functions like eval(), assert(), or create_function() should not be used with dynamic input. They allow arbitrary code execution and are a common vector in malware. Modern PHP and Magento provide safer alternatives to handle dynamic behavior securely.

Go to rule →

Path traversal protections

File access functions (fopen, file_get_contents, etc.) must validate and normalize paths. Without protections, attackers can perform directory traversal (../) to read or overwrite sensitive files. Always use realpath() checks and enforce base directory allow-lists.

Go to rule →

Secure file uploads

Upload handlers must validate MIME types, enforce extension allow-lists, limit file size, and store files outside webroot. Attackers often upload PHP shells disguised as images. Files should be re-encoded where possible and named randomly to avoid collisions.

Go to rule →

JS-context escaping

Variables injected into <script> blocks must be escaped with escapeJs() or JSON-encoded safely. Failing to escape JavaScript context enables reflected or stored XSS. This rule ensures Magento templates protect users against malicious scripts in dynamic content.

Go to rule →

Cryptographically secure RNG

Security tokens, nonces, and session identifiers must use CSPRNG functions (random_bytes, random_int). Insecure RNG (rand, mt_rand) can be predicted by attackers, enabling replay or token guessing. Cryptographically secure generators are mandatory for sensitive operations.

Go to rule →

Sensitive data not logged

Logs must not contain sensitive information such as passwords, API tokens, or card data. Attackers with log access can exploit leaked data. Magento logging should use sanitization filters and redact sensitive values before writing to files or monitoring systems.

Go to rule →

Use Magento APIs for crypto/session

Magento provides APIs for encryption, hashing, and session handling. Using PHP’s raw openssl_encrypt or custom session logic introduces misconfigurations and weak defaults. Always rely on platform-provided APIs to ensure consistency, upgrades, and strong security defaults.

Go to rule →

C04 — HTTPS & TLS Enforcement

Force HTTPS

All storefront and admin endpoints must use HTTPS to protect data in transit against eavesdropping and tampering. Enforce secure base URLs, redirect HTTP to HTTPS, and ensure cookies are only transmitted over TLS to maintain confidentiality and integrity.

Go to rule →

HSTS header enabled

HTTP Strict Transport Security (HSTS) instructs browsers to always use HTTPS, preventing downgrade and SSL‑strip attacks. Configure a strong max-age, include subdomains where appropriate, and preloading if eligible to ensure persistent TLS enforcement for returning users.

Go to rule →

TLS ≥ 1.2 only

Disable legacy protocols (SSLv3, TLS 1.0/1.1) and weak ciphers to reduce exposure to known cryptographic flaws. Require TLS 1.2+ with modern ciphers, forward secrecy, and robust key exchange settings to harden transport encryption across all entry points.

Go to rule →

No mixed content

Pages served over HTTPS must not load HTTP assets (scripts, styles, images). Mixed content undermines TLS guarantees and enables injection. Audit templates and CDN references, update asset URLs to HTTPS, and implement Content Security Policy to prevent accidental regressions.

Go to rule →

Secure cookies flags

Session and authentication cookies must set Secure, HttpOnly, and appropriate SameSite attributes. These flags reduce leakage over plaintext channels and mitigate XSS‑based theft or CSRF abuse. Validate headers and Magento configuration to consistently apply cookie protections.

Go to rule →

C05 — Production Mode & Deployment Hygiene

Magento in production mode

Production mode disables developer-specific features and optimizes performance. Running Magento in developer mode on production systems exposes debug output and slows execution. Always verify that production deployments explicitly set the correct mode to reduce risk and improve stability.

Go to rule →

No Xdebug on prod

Debugging extensions like Xdebug should never run on production servers. They introduce significant performance overhead and may expose sensitive data via traces or profiling endpoints. Confirm that php.ini does not load debugging modules in live environments.

Go to rule →

Display errors off

PHP error reporting must be logged, not displayed to users. Displaying stack traces or warnings reveals internal code paths and sensitive details. Ensure display_errors=Off in php.ini and configure Magento to mask detailed error messages in production.

Go to rule →

Compiled DI enabled

Magento’s Dependency Injection (DI) compilation generates optimized factories for production. Running without DI compilation forces runtime lookups, increasing attack surface and latency. Ensure setup:di:compile is executed during deployment, and the generated code is committed or built properly.

Go to rule →

Static assets deployed

Static view files (CSS, JS, images) should be deployed in advance using setup:static-content:deploy. Without pre-deployment, Magento may generate assets on the fly, leaking error details or causing downtime. Pre-built assets improve performance and reduce misconfiguration exposure.

Go to rule →

No dev configs on prod

Development configurations such as sandbox API keys, test SMTP servers, or verbose logging must not remain in production. They often bypass security controls and can leak sensitive data. Audit environment configs to ensure only production values are applied on live systems.

Go to rule →

C06 — Cache & Indexing Health

FPC enabled

Full Page Cache (FPC) significantly improves performance and reduces backend load. Disabling or misconfiguring FPC forces every request to hit PHP and the database, slowing responses and exposing bottlenecks. Always ensure FPC is enabled and serving cached content on production.

Go to rule →

Redis/Varnish configured

Magento supports advanced cache backends like Redis or Varnish. Without proper configuration, stores rely on file-based cache, which scales poorly and risks corruption. Using Redis or Varnish ensures faster cache invalidation, distributed caching, and higher resilience under heavy traffic.

Go to rule →

Indexers READY

Magento relies on indexers for search, pricing, and catalog performance. If indexers remain in “REINDEX REQUIRED” state, queries degrade severely, and features may fail. Regularly monitor and reindex to ensure indexers are healthy and data is up-to-date in production.

Go to rule →

Hardened session storage

Session data should never be stored in insecure file paths or world-writable locations. Redis with authentication or a database-backed session handler provides better isolation. Weak session storage exposes the risk of hijacking or leakage of sensitive authentication tokens.

Go to rule →

No dev cache backends

File-based caching is acceptable for local development but not suitable for clustered or production setups. Using file cache on shared hosts causes race conditions and stale content. Ensure production systems are configured to use Redis or Varnish backends exclusively.

Go to rule →

C07 — Logging & Monitoring

Protect application logs

Application logs must not be publicly accessible from the web. Attackers often scan for exposed var/log or server log files to gather sensitive information. Configure web server rules and file permissions to prevent direct download or browsing of log files.

Go to rule →

Log rotation

Large, unrotated log files can fill disks and cause denial of service. Rotation ensures logs are archived, compressed, and safely stored. Configure logrotate or equivalent tools to prevent excessive growth and maintain the availability of logging infrastructure.

Go to rule →

Safe exception handling

Exceptions must not expose stack traces or internal details to end users. Instead, return generic error pages while logging technical details securely. Exposed traces reveal file paths, libraries, and vulnerabilities that aid attackers in reconnaissance.

Go to rule →

PII sanitized in logs

Logs must avoid storing personally identifiable information (PII) such as names, emails, or payment data. If logging user data is unavoidable, values must be masked or hashed. Sanitizing logs reduces privacy risk and regulatory compliance issues.

Go to rule →

C08 — Cron Job Reliability

Crontab entries present

Magento relies heavily on cron jobs to run indexing, email sending, cache cleanup, and scheduled tasks. Missing crontab entries break essential background processes, leading to instability and delayed order processing. Verify that all required cron jobs are configured and active.

Go to rule →

Cron heartbeat healthy

A cron heartbeat confirms that scheduled jobs are running on time. If the heartbeat is stale or missing, tasks may be failing silently. Monitoring the cron schedule and alerting on failures ensures the continuous operation of business-critical background jobs.

Go to rule →

Cron backlog threshold

Excessive pending cron jobs indicate performance or configuration issues. A growing backlog delays time-sensitive tasks like order invoicing or email notifications. Regularly audit the queue length and alert if thresholds are exceeded to maintain healthy job execution.

Go to rule →

C09 — Extension Vulnerability Management

CVE match via OSV

Installed extensions must be scanned against OSV.dev and other vulnerability databases for known CVEs. Unpatched vulnerabilities in third-party modules are one of the top entry points for attackers. Regularly check advisories and flag modules with unresolved security issues.

Go to rule →

Core module advisories flagged

Vulnerabilities in official Magento core modules or Adobe-maintained packages must be tracked and patched immediately. Exploits against core components are widely weaponized, making this category highly critical. Automated scanning should alert whenever core advisories apply to the current version.

Go to rule →

Suggest fixed versions

When vulnerabilities are detected, stores should identify the patched version that resolves the issue. Providing recommended fixed versions helps developers upgrade quickly and avoid insecure builds. This minimizes exposure windows by guiding remediation paths clearly.

Go to rule →

High-risk surface modules flagged

Modules handling payment, authentication, or customer data represent high-risk attack surfaces. Even without known CVEs, they should be highlighted for extra scrutiny. Prioritizing code reviews and updates for these modules reduces overall compromise risk.

Go to rule →

Temporary mitigations documented

If patches are not yet available, temporary mitigations (e.g., disabling a feature, adding firewall rules) should be documented and applied. This ensures critical vulnerabilities are managed proactively, reducing risk while awaiting vendor-supplied fixes.

Go to rule →

Known exploited vulns prioritized

Vulnerabilities listed in CISA KEV or similar databases indicate active exploitation in the wild. Such extensions must be patched or disabled immediately. Prioritizing known exploited vulnerabilities is essential to reduce the likelihood of compromise by automated campaigns.

Go to rule →

Transitive dependency CVEs flagged

Extensions often rely on third-party PHP libraries that may contain vulnerabilities. Transitive dependencies must also be scanned for CVEs, not only top-level modules. Attackers frequently exploit weaknesses in bundled libraries overlooked by store operators.

Go to rule →

Constraints blocking fixes flagged

Composer version constraints can prevent applying patched releases. Overly strict constraints increase exposure windows by locking stores to insecure versions. Detecting and warning about such conflicts helps maintainers adjust constraints and apply timely updates.

Go to rule →

Yanked/withdrawn versions flagged

Composer packages marked as yanked or withdrawn should be flagged immediately. Yanked releases often indicate serious defects or vulnerabilities. Continuing to run these versions exposes stores to unpatched risks and should be remediated quickly.

Go to rule →

Outdated Marketplace extensions flagged

Marketplace modules without updates for long periods pose potential risks due to unpatched security issues. Highlighting outdated extensions encourages maintainers to review or replace them proactively. Staying current reduces the chance of silent exposure to known flaws.

Go to rule →

Advisory age/patch latency reported

Track how long advisories have been available compared to patch adoption. Long patch latency indicates operational risk. Reporting advisory age helps teams measure responsiveness and prioritize overdue updates across extensions.

Go to rule →

Extension with no vendor support flagged

Modules from vendors who no longer provide updates or have abandoned maintenance represent a critical long-term risk. Unsupported extensions should be flagged for replacement. Relying on unmaintained code increases exposure to unresolved vulnerabilities indefinitely.

Go to rule →

C10 — Abandoned Extensions Removal

Abandoned on Packagist

Extensions marked as “abandoned” on Packagist or Composer metadata should be immediately flagged. Abandoned modules no longer receive updates or security patches, leaving them permanently vulnerable. Replace such modules with maintained alternatives to reduce long-term security exposure.

Go to rule →

No release in >24 months

Extensions with no new release or update in over two years are strong indicators of abandonment. Old versions accumulate unpatched vulnerabilities over time. Monitoring release activity ensures outdated, stagnant modules are reviewed for replacement or removal.

Go to rule →

Archived repositories

GitHub or GitLab repositories marked “archived” signal that no further development will occur. Depending on the archived code poses a serious risk as future vulnerabilities will remain unaddressed. Such modules should be deprecated in production environments and migrated away from.

Go to rule →

Risky forks replacing originals

Forked modules maintained by unknown or unverified sources may lack security review. Depending on these forks introduces supply chain risk if malicious code is inserted. Always validate the reputation of maintainers and prefer official, actively supported repositories.

Go to rule →

C11 — Composer Dependency Hygiene

No wildcard constraints

Composer version constraints like * or dev-master allow uncontrolled upgrades, introducing unexpected vulnerabilities. Strict, semantic versioning ensures dependencies are predictable and security patches are applied consistently. Avoiding wildcards prevents accidental installation of insecure or unstable releases.

Go to rule →

No dev branches

Depending on the development branches (dev-branch) pulls unstable, unreviewed code into production. Such code may contain incomplete features or insecure implementations. Production environments must rely only on tagged, stable releases that receive security patches and long-term maintenance.

Go to rule →

Stable by default

Composer must be configured with prefer-stable=true to ensure stable packages are selected over unstable ones. Without this, unstable libraries may be chosen during dependency resolution. Enforcing stable preference reduces exposure to untested, insecure builds.

Go to rule →

Composer audit clean

Running composer audit checks dependencies against known CVE databases. Stores should fail builds if unresolved vulnerabilities are detected. Maintaining a clean audit report ensures critical vulnerabilities are addressed proactively and reduces exposure to compromised libraries.

Go to rule →

Direct deps up-to-date

Outdated direct dependencies accumulate unfixed vulnerabilities. Regularly updating core libraries and Magento packages ensures access to the latest security patches. Monitoring update frequency helps maintainers avoid lagging behind on critical dependency fixes.

Go to rule →

Lockfile integrity

The composer.lock file should be committed to version control and remain consistent with composer.json. Missing or outdated lockfiles cause uncontrolled dependency drift, leading to insecure or inconsistent builds. Validating lockfile integrity ensures deterministic, secure deployments.

Go to rule →

Disallow abandoned PHP libs

PHP libraries marked abandoned by maintainers should not remain in production. Relying on unsupported libraries increases long-term risk as vulnerabilities will not be patched. Audit dependency trees regularly and replace abandoned libraries with supported alternatives.

Go to rule →

C12 — Third‑party Config Security

No secrets in VCS

API keys, tokens, and credentials must never be committed to source control or copied into sample configs. Secret exposure enables account takeover and data exfiltration. Use environment variables, secret managers, and pre‑commit scanners to prevent accidental leaks across repositories.

Go to rule →

HTTPS‑only endpoints

All third‑party integrations—including payment, shipping, email, and analytics—must use HTTPS with valid certificates. Plain HTTP exposes tokens and PII to interception or tampering. Validate endpoint schemes in configuration, enforce TLS at proxies, and block insecure URLs during deployment.

Go to rule →

Debug/verbose disabled in prod

Third‑party modules often include debug or verbose logging modes that reveal requests, headers, or credentials. These settings must be disabled in production scopes. Audit configuration per environment and verify no debug endpoints or inspector UIs are reachable on public networks.

Go to rule →

Webhook signature validation

Inbound webhooks must be authenticated using HMAC or signed tokens to prevent spoofing. Without validation, attackers can forge events, trigger refunds, or alter orders. Configure shared secrets, rotate periodically, and reject requests lacking correct signatures or timestamps.

Go to rule →

Outbound allow‑list enforced

Egress traffic for integrations should be restricted to an allow‑listed set of hostnames or IP ranges. Unrestricted outbound requests increase SSRF blast radius and data exfiltration risk. Enforce DNS pinning, firewall rules, or HTTP client allow‑lists to constrain destinations.

Go to rule →

PII minimization in configs

Configuration values must avoid storing unnecessary personal data such as full addresses, phone numbers, or payment metadata. Prefer transient tokens and references. Minimizing PII reduces breach impact, simplifies compliance, and limits incidental exposure through logs, backups, or misconfigurations.

Go to rule →

Payment gateway configs use strong TLS ciphers

Payment integrations must negotiate modern TLS versions and recommended cipher suites. Weak protocols or ciphers invite downgrade and interception attacks. Validate with automated TLS scanners, monitor gateway announcements, and enforce strict security profiles at load balancers and edge proxies.

Go to rule →

API keys stored in env.php, not DB/plaintext

Secrets should live in app/etc/env.php or a secret manager, never in database rows or plaintext admin settings. Database‑stored keys tend to proliferate across environments and backups. Centralized storage simplifies rotation and restricts access via filesystem permissions.

Go to rule →

Third‑party logging sanitized

Integration logs should redact tokens, session IDs, customer identifiers, and request bodies containing PII. Many SDKs log full payloads by default. Configure allow‑lists for safe fields, enable masking filters, and periodically review log samples for accidental sensitive data exposure.

Go to rule →

Cloud/SaaS integrations restricted by ACL

Accounts used for SaaS connectors must follow least privilege. Assign scoped API roles, restrict IP ranges, and separate production from sandbox tenants. Over‑permissioned API users amplify blast radius when credentials leak, enabling destructive actions beyond the integration’s intended purpose.

Go to rule →

The Security Baseline for Magento 2

81 rules to keep your magento store secure. Filter by Magebean Controls or OWASP Top 10.

Group by: