playbooks

home / skills / mastra-ai / mastra / security-review

security-review skill

/templates/template-github-review-agent/workspace/skills/security-review

This skill helps you perform a security-focused code review by applying a comprehensive checklist to identify vulnerabilities across categories.

npx playbooks add skill mastra-ai/mastra --skill security-review

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
2.0 KB
---
name: security-review
description: Security-focused code review checklist for identifying vulnerabilities
version: 1.0.0
metadata:
  tags:
    - code-review
    - security
---

# Security Review

When reviewing code for security issues, check each category below. Reference the detailed checklist in `references/security-checklist.md`.

## Injection Vulnerabilities

- SQL injection: Look for string concatenation in database queries
- Command injection: Check for unsanitized input passed to shell commands (`exec`, `spawn`)
- XSS: Look for unsanitized user input rendered in HTML/templates
- Path traversal: Check for user input in file paths without sanitization

## Authentication & Authorization

- Verify authentication checks on protected routes/endpoints
- Ensure authorization checks match the required access level
- Look for privilege escalation paths (e.g., user can modify other users' data)
- Check that password/token comparison uses constant-time comparison

## Secrets & Credentials

- Hardcoded API keys, passwords, tokens, or connection strings
- Secrets in configuration files that might be committed
- Sensitive data in logs or error messages
- Credentials passed via URL query parameters

## Input Validation

- Validate and sanitize all external input (user input, API responses, file contents)
- Check for missing or weak input validation on API endpoints
- Verify type coercion doesn't bypass validation
- Look for overly permissive CORS or CSP configurations

## Data Exposure

- Sensitive data returned in API responses unnecessarily
- PII or secrets in application logs
- Information leakage in error messages (stack traces, internal paths)
- Missing data encryption for sensitive fields

## Severity Levels

- 🔴 **CRITICAL**: Exploitable vulnerability (injection, auth bypass, exposed secrets)
- 🟠 **HIGH**: Potential vulnerability that needs investigation
- 🟡 **MEDIUM**: Security weakness or missing best practice
- 🔵 **LOW**: Minor security improvement suggestion

Overview

This skill provides a focused security code-review checklist to help identify common vulnerabilities in TypeScript and JavaScript projects. It highlights injection risks, authentication and authorization gaps, secret leaks, input validation issues, and data exposure problems. The goal is to make reviews faster and to prioritize fixes by severity.

How this skill works

The skill inspects code patterns and review concerns across common attack surfaces: database queries, shell invocation, template rendering, file access, and API endpoints. It guides reviewers to look for hardcoded secrets, missing auth checks, weak validation, and sensitive data leakage, and maps findings to clear severity levels for triage. Use the checklist as a repeatable linting companion during pull-request reviews or security audits.

When to use it

  • During pull-request reviews for backend and frontend changes
  • Before merging features that touch authentication, file I/O, or external commands
  • When onboarding new reviewers to enforce consistent security checks
  • During security sprints or pre-release audits
  • When adding third-party integrations or changing configuration handling

Best practices

  • Search for string concatenation in queries and prefer parameterized queries or ORM bindings
  • Reject unsanitized input to shells and prefer safe APIs instead of exec/spawn
  • Enforce authorization checks at business-logic boundaries, not only in UI layer
  • Keep secrets out of source and logs; use environment variables and secret managers
  • Validate and sanitize all external inputs; use strict typing and schema validation
  • Avoid returning PII or stack traces in API responses; log minimally and securely

Example use cases

  • Spotting SQL or command injection patterns in a new feature that builds queries dynamically
  • Verifying authentication and role checks on new API endpoints
  • Finding accidentally committed API keys or credentials in configuration changes
  • Auditing CORS/CSP and input validation for a public-facing API
  • Checking for excessive data returned by endpoints that may expose PII

FAQ

What severity level should I assign for a leaked API key in code?

Treat exposed API keys or credentials as CRITICAL because they are immediately exploitable; rotate keys and remove them from code.

How do I handle findings about missing input validation?

Classify missing validation as MEDIUM if no immediate exploit is visible, but prioritize adding schema validation and sanitization before release.