| name | backend-security-coder |
| description | Secure backend coding for djzeneyer.com, especially WordPress/PHP plugins, REST APIs, auth boundaries, sanitization, escaping, SQL safety, CSP/CORS and public/private data classification. |
| risk | medium |
| source | community-adapted |
| updated | 2026-05-30 |
Backend Security Coder — djzeneyer.com
Purpose
Apply secure backend coding practices to the real project stack:
- WordPress custom plugins.
- PHP 8.3+.
- WordPress REST API.
- JWT/Google OAuth via
zeneyer-auth.
- LiteSpeed/Cloudflare/CSP/CORS.
- Public AI/search resources by design.
This skill is for secure implementation and review. For CodeQL-specific findings, use codeql-security first. For REST endpoint design, use wp-rest-api. For auth architecture, use auth-implementation-patterns + wp-headless.
For WordPress plugin code review, use wp-plugin-code-reviewer first and this skill as its security checklist. WordPress Coding Standards are the primary style authority for plugin PHP in this project.
Project-specific security posture
Do not treat intentional public product surfaces as leaks:
- Public artist payment/support data such as Pix, PayPal, Wise, IBAN/SWIFT/bank fields are public by design when they are the artist's own support/payment details.
- Public AI/search resources are public by design:
llms*, .well-known/*, API catalog, MCP/server card, Agent Skills public resources, schema and Content Signals.
- Public content may be used for search, grounding, discovery, indexing and AI training.
Still private:
- User data.
- Sessions and JWT secrets.
- Passwords and reset tokens.
- API/SMTP/secrets.
- Private order/customer/payment details.
- Third-party payment data not owned by the artist.
If a finding could be either intentional product behavior or a leak, ask the human before changing behavior.
When to use
Use this skill when:
- Reviewing or writing PHP plugin code.
- Creating/changing REST endpoints.
- Handling user input/output.
- Touching authentication, authorization, sessions or JWT.
- Handling external requests, webhooks or remote content.
- Changing CSP, CORS, headers or
.htaccess behavior.
- Fixing security alerts.
Core rules
Input and output
- Validate/sanitize input early.
- Escape output late.
- Use context-appropriate WordPress escaping.
- Never echo raw
$_GET, $_POST, DB values or remote API data.
- Use
wp_unslash() before sanitizing request superglobals.
| Context | Function |
|---|
| HTML text | esc_html() |
| HTML attribute | esc_attr() |
| URL output | esc_url() |
| URL storage/redirect | esc_url_raw() |
| Textarea | esc_textarea() |
| Limited safe HTML | wp_kses() |
| Integer/ID | absint() |
| Text input | sanitize_text_field() |
| Key/slug | sanitize_key() |
| Email | sanitize_email() |
SQL
- Always use
$wpdb->prepare().
- Prefer WordPress APIs over raw SQL.
- For WooCommerce HPOS, use
wc_get_orders(), not SQL over wp_posts.
- GamiPress helpers such as
gamipress_get_rank_types() return associative arrays. Use array_values() or reset() for the first element, never $array[0].
REST API
- Every route needs
permission_callback.
- Public endpoints use
__return_true only when data is intentionally public.
- Authenticated endpoints require JWT/user identity/capability checks.
- Admin endpoints require capability checks such as
manage_options.
- Use
WP_Error with explicit status for failures.
- Sanitize args via
args schema and request methods, not raw superglobals.
Auth and sessions
- Never log tokens, secrets or credentials.
- Validate JWT signature and expiry.
- Keep auth logic aligned with
zeneyer-auth patterns.
- Avoid broad role assumptions. Check exact capabilities.
CSP, CORS and headers
- CSP is generated dynamically in
inc/csp.php. Do not unset it in .htaccess.
- HSTS is managed by Cloudflare. Do not create a second source of truth in
.htaccess.
- Never use wildcard CORS with credentials.
- YouTube/embed header issues should be solved in CSP/iframe allow rules, not by disabling CSP globally.
External requests
- Validate URLs and protocols.
- Add timeouts to
wp_remote_get() / wp_remote_post().
- Fail closed or degrade gracefully.
- Avoid SSRF by not fetching arbitrary user-provided URLs unless allowlisted or heavily validated.
CodeQL alignment
Before writing sanitization or HTML stripping code, read codeql-security.
Important patterns:
- Avoid tag-specific regex stripping like
<script\b...>.
- Prefer generic loop removal and final sweep for plain-text strip use cases.
- Use
sanitizeHtml() for trusted allowlisted HTML in React.
- Every
dangerouslySetInnerHTML must have approved sanitization.
Review checklist
Output format
Security scope:
Data classification:
Threat/risk:
Recommended implementation:
Validation:
Open questions:
When not to use
Do not use this skill for pure frontend UI, copy, SEO metadata, non-security performance work or content strategy unless there is a security boundary involved.
