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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
No PAN, CVV, or track data stored in database
Magento databases must not store raw card numbers, CVV, magnetic stripe data, or equivalent sensitive authentication data unless the environment is intentionally in full PCI DSS scope and protected accordingly. Scan schema names, payment tables, custom extension tables, and sampled values for cardholder data indicators. Tokenized references and provider customer IDs are preferred over raw payment data.
Payment method scope detection
Payment integrations should be classified by how they handle card data, such as hosted redirect, hosted fields, iframe/tokenized fields, direct post, or custom raw card collection. This classification helps identify PCI scope and risk before remediation planning. Detect enabled payment modules, checkout templates, provider SDKs, and custom payment implementations to flag scope-expanding patterns.
Payment page script inventory maintained
Every script loaded on payment pages should be inventoried with its source, owner, business justification, and authorization status. Untracked third-party scripts are a major source of Magecart-style compromise. Enumerate checkout layout XML, templates, CMS blocks, CSP whitelists, and rendered payment pages to build an auditable script inventory.
Payment page script allowlist and integrity controls
Payment-page scripts should be constrained by allowlists and integrity controls such as SRI, hashes, signed deployment manifests, CSP nonces, or approved monitoring. Without integrity controls, compromised third-party JavaScript or injected snippets can skim card data in the browser. Validate that only approved script origins and expected script assets can execute on checkout.
Payment webhook endpoint authentication hardening
Payment callbacks and webhooks must validate signatures, timestamps, replay windows, and provider-specific authentication requirements before processing order or payment state changes. Weak webhook validation can enable forged payment success, refund abuse, or order manipulation. Enforce provider HMAC verification, secret rotation, idempotency, and logging of rejected events. security-audit: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Run Magebean Audit run: /path-to-file/magebean.phar scan --path=. Exploitation can lead to full system compromise, data breach, or payment fraud. Must be remediated immediately. Exploitation can cause significant security or operational risk, such as privilege escalation or data leakage. Should be prioritized for remediation. Exploitation has limited impact or requires additional conditions. Important to fix but may be scheduled. Minor security hygiene issues or best practices. Fix as part of normal maintenance.
