Security Pitfalls Drupal Module Maintainers Should Avoid

Pierre Rudloff Maps Recurring Security Patterns in Drupal Contributed Modules
Security Pitfalls Drupal Module Maintainers Should Avoid

Most Drupal security advisories are not triggered by exotic exploits. They stem from small, preventable oversights: a missing access check, an unsafe Twig filter, an unprotected route, or a dependency pinned too tightly.

After reviewing two years of Drupal security advisories and the patches that addressed them, Pierre Rudloff compiled recurring vulnerability patterns into the Drupal Security Tips repository. The project documents implementation mistakes that repeatedly led to contributed module advisories.

This overview highlights the most common risk categories. For detailed technical examples, maintainers should review the linked documentation.

1. Cross-Site Scripting (XSS): Small bypasses, big impact

XSS remains one of the most common vulnerabilities in contributed modules. Drupal’s render system and Twig’s auto-escaping provide strong defaults, but these protections can be bypassed unintentionally.

See the XSS guidance and the OWASP XSS overview.

  • Do not trust values passed through data-* attributes.
  • Avoid inserting user input with .html(); prefer .text().
  • Never use Markup::create() on unfiltered user input.
  • Avoid Twig’s |raw unless the content is explicitly safe.

2. SVG files are executable content

SVG files can contain embedded JavaScript and should be treated as executable content rather than harmless images.

Reference: SVG security guidance.

  • Do not allow untrusted users to upload SVG files without sanitization.
  • Use a dedicated SVG sanitization library.
  • Prefer sanitizing at display time so updates protect previously uploaded files.

3. CSRF: Protect every state-changing route

Routes that create, update, or delete data without confirmation are vulnerable to CSRF attacks.

See the CSRF guidance and the OWASP CSRF reference.

  • Use _csrf_token: 'TRUE' for state-changing routes without forms.
  • Do not assume GET routes are harmless.
  • Use _csrf_request_header_token where appropriate for non-form routes.

4. Access checks: Permissions are not enough

Access control mistakes frequently lead to advisories when routes bypass entity-level access hooks.

Detailed guidance: Access checks documentation.

  • Avoid _access: 'TRUE' in routes.
  • Use _entity_access and _entity_create_access for entity routes.
  • Ensure Views define explicit access conditions.
  • Remember #access may return an AccessResultInterface.

5. Authentication: The login form is not the only entry point

Modules that extend login workflows must account for alternative authentication mechanisms.

See the Authentication guidance.

  • Consider core’s REST login route.
  • Account for additional authentication providers.
  • Use the Flood service to limit brute-force attempts.

6. Dependency management is part of security

Third-party library management affects how quickly sites can apply upstream security patches.

Reference: Dependency management guidance.

  • Do not commit third-party libraries directly into module repositories.
  • Use Composer for PHP dependencies.
  • Avoid exact version pinning; allow compatible version ranges.
  • Avoid duplicating upstream code when possible.

7. Permissions and external redirects

Permissions that allow high-risk actions should be explicitly restricted.

See the Permissions guidance.

  • Use restrict access: true for dangerous permissions.
  • Keep restricted permission scopes narrow.
  • Treat external redirects as high-risk functionality.

8. Regular expressions and ReDoS

Regular expressions can be fragile when parsing untrusted input.

Reference: Regular expression guidance.

  • Prefer dedicated parsers for structured input.
  • Check for NULL returns from preg_* functions.

9. Server-Side Request Forgery (SSRF)

Modules performing outbound HTTP requests based on user input must restrict destinations.

See the SSRF guidance and the OWASP SSRF overview.

  • Never allow arbitrary URLs without validation.
  • Use an administrator-configurable allowlist of domains.

Reporting security issues

If maintainers discover a vulnerability, they should follow Drupal’s coordinated disclosure process via the official security reporting guidelines.

Reviewing modules against these categories can reduce preventable risk and strengthen contributed project resilience.

Note: The vision of this web portal is to help promote news and stories around the Drupal community and promote and celebrate the people and organizations in the community. We strive to create and distribute our content based on these content policy. If you see any omission/variation on this please reach out to us at #thedroptimes channel on Drupal Slack and we will try to address the issue as best we can.

Upcoming Events