From security-engineer
Structured web application security assessment following OWASP methodology. Covers authentication, authorisation, input validation, session management, API security, and security headers. Use during penetration testing or security reviews of web applications.
npx claudepluginhub hpsgd/turtlestack --plugin security-engineerThis skill is limited to using the following tools:
Conduct a structured web application security assessment of $ARGUMENTS.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Designs, implements, and audits WCAG 2.2 AA accessible UIs for Web (ARIA/HTML5), iOS (SwiftUI traits), and Android (Compose semantics). Audits code for compliance gaps.
Conduct a structured web application security assessment of $ARGUMENTS.
[!IMPORTANT] This skill requires explicit written authorisation for the target application. Active testing sends requests to the target — this is not passive. Confirm the Rules of Engagement before running any active checks. Never test production systems without written authorisation that explicitly includes production.
Log before starting:
Before active testing, run /security:recon for passive domain and technology intelligence. This establishes what you're dealing with before touching the application.
From the recon output, note:
Test the authentication implementation:
Credential testing:
Password policy:
MFA:
Password reset flow:
Session token quality:
Cookie attributes:
HttpOnly — prevents JavaScript accessSecure — HTTPS onlySameSite — CSRF mitigationSession lifecycle:
Horizontal privilege escalation: Test whether user A can access user B's resources by modifying object IDs (IDOR — Insecure Direct Object Reference).
Common pattern: change /api/orders/12345 to /api/orders/12346 while authenticated as a different user. Access to another user's data = IDOR.
Vertical privilege escalation: Test whether a low-privilege user can access admin or elevated functions.
Common pattern: capture an admin request in proxy, replay it authenticated as a standard user.
Forced browsing: Directly access URLs that are not linked from the authenticated UI. Are they protected by authentication checks or only hidden by obscurity?
Focus on the OWASP Top 10 injection categories:
SQL injection:
', ' OR '1'='1, '; DROP TABLE (in non-production only)sqlmap in safe mode for systematic testing: sqlmap -u "[URL]" --forms --batch --level=1XSS (Cross-Site Scripting):
<script>alert(1)</script> — if this executes, it's XSSinnerHTML, document.write, eval() with user-controlled dataSSRF (Server-Side Request Forgery):
http://169.254.169.254/latest/meta-data/ (AWS metadata), http://localhost/, internal hostnamesXXE (XML External Entity):
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>Command injection:
; id, | id, && idCheck HTTP response headers on the application's main page and authenticated sections:
curl -I -s "[URL]" | grep -i -E "strict-transport|content-security|x-frame|x-content-type|referrer-policy|permissions-policy"
| Header | Expected value | Risk if absent |
|---|---|---|
Strict-Transport-Security | max-age=31536000; includeSubDomains | Downgrade attack |
Content-Security-Policy | Restrictive policy | XSS escalation |
X-Frame-Options | DENY or SAMEORIGIN | Clickjacking |
X-Content-Type-Options | nosniff | MIME sniffing |
Referrer-Policy | strict-origin-when-cross-origin | Data leakage in referrer |
If the application has an API:
/api/docs, /swagger, /openapi.json)## Web application assessment: [Target]
**Engagement:** [authorisation reference]
**Date:** [today]
**Environment:** [production / staging / test]
**Scope:** [URLs and functionality in scope]
### Executive summary
[2-3 sentences: overall risk posture and the 1-2 most significant findings]
### Findings
#### [Finding title] — [Critical / High / Medium / Low / Informational]
**CVSS score (if applicable):** —
**Affected component:** —
**Description:** [what the vulnerability is]
**Evidence:** [specific request/response or screenshot reference]
**Impact:** [what an attacker could do]
**Remediation:** [specific fix recommendation]
### Security headers
| Header | Present | Value | Assessment |
|---|---|---|---|
### Summary table
| Finding | Severity | Status |
|---|---|---|
| [Finding] | Critical / High / Medium / Low | Open |
### Out-of-scope observations
[Potential issues noticed outside the agreed scope — noted for client awareness, not tested]