From drupal-core
Comprehensive security auditing workflow for Drupal sites. Covers user accounts, role permissions, module inventory, site configuration, text formats, views access, file exposure, content injection scanning, and integration with the security_review contrib module. Use when performing security assessments, hardening a Drupal site, or investigating potential vulnerabilities.
npx claudepluginhub ajv009/drupal-devkitThis skill uses the workspace's default tool permissions.
Perform comprehensive, read-only security assessments of a Drupal site. Produce a clear, actionable report organized by severity. Never make changes to the site during an audit.
Guides WordPress penetration testing: enumerates users/themes/plugins, scans vulnerabilities with WPScan/Nmap, targets WP 7.0 surfaces like RTC/AI API/Abilities.
Provides OWASP security patterns for Drupal 10/11 including SQL injection prevention, XSS filtering, route access control, and custom checkers. Use for code security reviews and hardening.
Audits WordPress HTTPS/SSL config: checks siteurl/home URL schemes and FORCE_SSL_ADMIN via WP-CLI (if available), scans PHP/JS files for hardcoded http:// mixed-content URLs.
Share bugs, ideas, or general feedback.
Perform comprehensive, read-only security assessments of a Drupal site. Produce a clear, actionable report organized by severity. Never make changes to the site during an audit.
A complete security audit follows five phases. Each phase can also be run independently for targeted reviews.
The security_review contrib module provides a suite of automated checks. When it is available:
If the module is not installed, skip to Phase 2 -- all custom audits work independently.
Audit user accounts and role permissions for common misconfigurations:
administer modules, bypass node access, use PHP for settings, synchronize configuration, etc.). Permissions on the anonymous and authenticated roles are especially critical.| Severity | Permissions |
|---|---|
| Critical | use PHP for settings, administer modules, administer software updates, administer site configuration, administer permissions, administer users, bypass node access, synchronize configuration, import configuration, administer filters |
| Warning | administer content types, administer taxonomy, administer views, administer blocks, access site reports, administer menu, administer nodes, use text format full_html, access all views, administer search |
Any administer * permission on anonymous or authenticated roles is a critical finding.
Review site-level settings and the module landscape:
display_errors / expose_php settings.none). These are publicly reachable without restriction.devel, kint, webprofiler, field_ui, views_ui, dblog in production) and unsupported / dev-version modules..git/, .env, phpinfo.php, SQL dumps, backup archives, CHANGELOG.txt, INSTALL.txt).Scan content entities for potential stored XSS or PHP injection:
<script, <?php, <iframe, javascript:, eval(.Organize all findings into a severity-ranked report:
| Section | Contents |
|---|---|
| Executive Summary | Overall security posture with Critical / Warning / Info counts |
| Critical Issues | Must-fix immediately -- data exposure, code execution risks |
| Warnings | Should be addressed soon -- information disclosure, best-practice violations |
| Informational | Nice-to-have improvements |
| Recommendations | Prioritized action items with specific remediation steps |
For every finding, explain why it is a security concern, not just what was found.
The audit relies on 12 dedicated read-only tools plus 2 module-management helpers:
| # | Tool | Operation | Description | Key Parameters |
|---|---|---|---|---|
| 1 | list_security_checks | Read | Lists all security_review checks with ID, title, skip status, and last result | -- |
| 2 | run_security_review | Read | Runs all or specific security_review checks; returns pass/fail/warn/info summary | checks: "all" or JSON array of check IDs |
| 3 | get_check_details | Read | Gets detailed findings and remediation help for a single check | check_id (required): plugin ID, e.g. "admin_user" |
| 4 | audit_users | Read | Audits user accounts: uid 1 status, privileged users, recent accounts, blocked accounts | audit_type: "all", "uid1", "privileged", "recent", "blocked" |
| 5 | audit_role_permissions | Read | Scans roles for dangerous permissions; flags anonymous/authenticated escalations | role: machine name or "all" |
| 6 | check_site_configuration | Read | Checks error reporting, trusted hosts, cron, private files, PHP settings | -- |
| 7 | check_input_formats | Read | Audits text formats for missing HTML filtering, PHP code filter, dangerous tags | -- |
| 8 | check_views_access | Read | Finds Views displays with no access control | -- |
| 9 | audit_enabled_modules | Read | Flags development and risky modules in production | -- |
| 10 | check_security_updates | Read | Reports modules/core with known security vulnerabilities via Update Manager | -- |
| 11 | check_dangerous_files | Read | Scans webroot for .git/, .env, phpinfo.php, SQL dumps, backups, info files | -- |
| 12 | scan_content_for_injections | Read | Scans entity text fields for <script, <?php, <iframe, javascript:, eval( | entity_type: defaults to "node"; limit: defaults to "100" |
| 13 | enable_module | Write | Enables a Drupal module (from ai_agents_module_manager) | module name |
| 14 | disable_module | Write | Disables a Drupal module (from ai_agents_module_manager) | module name |
Tools 1-3 require the security_review contrib module to be enabled. Tools 4-12 work without any contrib dependencies. Tools 13-14 are used only for temporarily enabling/disabling security_review when needed.
"Run a complete security audit of the site"
Execute all five phases in order. If security_review is not already enabled, enable it for the audit and disable it when finished. Compile a full severity-ranked report.
"Audit all user accounts for suspicious activity"
Use audit_users with audit_type="all" to check uid 1 status, list all privileged users, review recently created accounts, and inspect blocked accounts. Follow up with audit_role_permissions to check what each role can do.
"Check the permissions assigned to each role for dangerous access"
Run audit_role_permissions with role="all". Focus on anonymous and authenticated roles first. Any administer * permission on these roles is a critical finding. Provide specific remediation: which permissions to revoke and why.
"Check if there are any security updates available"
Run check_security_updates to query Update Manager data. For each finding, report the project name, current version, and recommended security release. Also run audit_enabled_modules to flag dev-version or unsupported modules.
"Check the site configuration for security issues"
Run check_site_configuration, check_input_formats, and check_views_access together. Look for error messages exposed to visitors, missing trusted-host patterns, text formats with the PHP code filter, and Views with no access restrictions.
"Scan the content for potential XSS or injection attacks"
Run scan_content_for_injections with default parameters to scan up to 100 nodes. For larger sites, increase the limit or target specific entity types. Report any entities containing suspicious patterns with their entity ID and field name.
"Are there any dangerous files in the web root?"
Run check_dangerous_files to scan for .git/, .env, phpinfo.php, SQL dumps, backup archives, and Drupal info files that should not be publicly accessible. Each finding includes the file path and the security risk it poses.
security_review when needed).security_review was enabled for the audit, disable it afterward to leave the site in its original state.