agentsclimarketplace

Security review

Skill Lukk17/agent-standards/.agents/skills/security-review

Use this skill when adding authentication, handling user input, working with secrets, creating API endpoints, or implementing payment/sensitive features. Provides comprehensive security checklist and patterns.From its SKILL.md

Install
npx -y skills add Lukk17/agent-standards --skill security-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

17.5 KB, ~4.3k tokens by cl100k_base, as published. Nobody here has run it

Security Review Skill

This skill ensures all code follows security best practices and identifies potential vulnerabilities.


When to Activate

  • Implementing authentication or authorization
  • Handling user input or file uploads
  • Creating new API endpoints
  • Working with secrets or credentials
  • Implementing payment features
  • Storing or transmitting sensitive data
  • Integrating third-party APIs

Security Checklist

1. Secrets Management

FAIL: NEVER Do This
const apiKey = "sk-proj-xxxxx"  // Hardcoded secret
const dbPassword = "password123" // In source code
PASS: ALWAYS Do This
const apiKey = process.env.OPENAI_API_KEY
const dbUrl = process.env.DATABASE_URL

// Verify secrets exist
if (!apiKey) {
  throw new Error('OPENAI_API_KEY not configured')
}
Verification Steps
  • No hardcoded API keys, tokens, or passwords
  • All secrets in environment variables
  • .env.local in .gitignore
  • No secrets in git history
  • Production secrets in hosting platform (Vercel, Railway)

2. Input Validation

Always Validate User Input
import { z } from 'zod'

// Define validation schema
const CreateUserSchema = z.object({
  email: z.string().email(),
  name: z.string().min(1).max(100),
  age: z.number().int().min(0).max(150)
})

// Validate before processing
export async function createUser(input: unknown) {
  try {
    const validated = CreateUserSchema.parse(input)
    return await db.users.create(validated)
  } catch (error) {
    if (error instanceof z.ZodError) {
      return { success: false, errors: error.errors }
    }
    throw error
  }
}
File Upload Validation
function validateFileUpload(file: File) {
  // Size check (5MB max)
  const maxSize = 5 * 1024 * 1024
  if (file.size > maxSize) {
    throw new Error('File too large (max 5MB)')
  }

  // Type check
  const allowedTypes = ['image/jpeg', 'image/png', 'image/gif']
  if (!allowedTypes.includes(file.type)) {
    throw new Error('Invalid file type')
  }

  // Extension check
  const allowedExtensions = ['.jpg', '.jpeg', '.png', '.gif']
  const extension = file.name.toLowerCase().match(/\.[^.]+$/)?.[0]
  if (!extension || !allowedExtensions.includes(extension)) {
    throw new Error('Invalid file extension')
  }

  return true
}

Always validate magic bytes (binary signature), not just extension or MIME header:

import magic

def validate_upload(file_bytes: bytes, allowed_types: list[str]) -> bool:
    # Check binary signature (magic bytes) — not just extension or MIME header
    detected = magic.from_buffer(file_bytes, mime=True)
    return detected in allowed_types
Verification Steps
  • All user inputs validated with schemas
  • File uploads restricted (size, type, extension)
  • No direct use of user input in queries
  • Whitelist validation (not blacklist)
  • Error messages don't leak sensitive info

3. SQL Injection Prevention

FAIL: NEVER Concatenate SQL
// DANGEROUS - SQL Injection vulnerability
const query = `SELECT * FROM users WHERE email = '${userEmail}'`
await db.query(query)
PASS: ALWAYS Use Parameterized Queries
// Safe - parameterized query
const { data } = await supabase
  .from('users')
  .select('*')
  .eq('email', userEmail)

// Or with raw SQL
await db.query(
  'SELECT * FROM users WHERE email = $1',
  [userEmail]
)
Verification Steps
  • All database queries use parameterized queries
  • No string concatenation in SQL
  • ORM/query builder used correctly
  • Supabase queries properly sanitized

4. Authentication & Authorization

JWT Token Handling
// FAIL: WRONG: localStorage (vulnerable to XSS)
localStorage.setItem('token', token)

// PASS: CORRECT: httpOnly cookies
res.setHeader('Set-Cookie',
  `token=${token}; HttpOnly; Secure; SameSite=Strict; Max-Age=3600`)
Authorization Checks
export async function deleteUser(userId: string, requesterId: string) {
  // ALWAYS verify authorization first
  const requester = await db.users.findUnique({
    where: { id: requesterId }
  })

  if (requester.role !== 'admin') {
    return NextResponse.json(
      { error: 'Unauthorized' },
      { status: 403 }
    )
  }

  // Proceed with deletion
  await db.users.delete({ where: { id: userId } })
}
Password Hashing
  • Primary (recommended): Argon2id: argon2-cffi (Python) / Argon2PasswordEncoder (Spring)
  • Acceptable fallback: BCrypt with cost factor >= 12
  • Prohibited: MD5, SHA-1, SHA-256 (unsalted), PBKDF2 with < 100,000 iterations
# Python — argon2-cffi
from argon2 import PasswordHasher

ph = PasswordHasher()
hash = ph.hash(password)         # hash and store
ph.verify(hash, password)        # verify on login
// Spring Security
PasswordEncoder encoder = new Argon2PasswordEncoder(16, 32, 1, 65536, 3);
String hash = encoder.encode(rawPassword);
encoder.matches(rawPassword, hash);
Row Level Security (Supabase)
-- Enable RLS on all tables
ALTER TABLE users ENABLE ROW LEVEL SECURITY;

-- Users can only view their own data
CREATE POLICY "Users view own data"
  ON users FOR SELECT
  USING (auth.uid() = id);

-- Users can only update their own data
CREATE POLICY "Users update own data"
  ON users FOR UPDATE
  USING (auth.uid() = id);
Verification Steps
  • Tokens stored in httpOnly cookies (not localStorage)
  • Authorization checks before sensitive operations
  • Row Level Security enabled in Supabase
  • Role-based access control implemented
  • Session management secure

5. XSS Prevention

Sanitize HTML
import DOMPurify from 'isomorphic-dompurify'

// ALWAYS sanitize user-provided HTML
function renderUserContent(html: string) {
  const clean = DOMPurify.sanitize(html, {
    ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'p'],
    ALLOWED_ATTR: []
  })
  return <div dangerouslySetInnerHTML={{ __html: clean }} />
}
Content Security Policy

Rule: No unsafe-inline or unsafe-eval in Content Security Policy. Use nonces for inline scripts/styles if necessary.

// next.config.js
const nonce = generateSecureNonce() // cryptographically random per request

const securityHeaders = [
  {
    key: 'Content-Security-Policy',
    value: [
      "default-src 'self'",
      `script-src 'self' 'nonce-${nonce}'`,
      `style-src 'self' 'nonce-${nonce}'`,
      "img-src 'self' data:",
      "font-src 'self'",
      "frame-ancestors 'none'",
      "base-uri 'self'",
    ].join('; ')
  }
]

Full recommended CSP header:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; style-src 'self' 'nonce-{random}'; img-src 'self' data:; font-src 'self'; frame-ancestors 'none'; base-uri 'self'
Verification Steps
  • User-provided HTML sanitized
  • CSP headers configured with nonces: no unsafe-inline or unsafe-eval
  • No unvalidated dynamic content rendering
  • React's built-in XSS protection used

6. CSRF Protection

CSRF Tokens
import { csrf } from '@/lib/csrf'

export async function POST(request: Request) {
  const token = request.headers.get('X-CSRF-Token')

  if (!csrf.verify(token)) {
    return NextResponse.json(
      { error: 'Invalid CSRF token' },
      { status: 403 }
    )
  }

  // Process request
}
SameSite Cookies
res.setHeader('Set-Cookie',
  `session=${sessionId}; HttpOnly; Secure; SameSite=Strict`)
Verification Steps
  • CSRF tokens on state-changing operations
  • SameSite=Strict on all cookies
  • Double-submit cookie pattern implemented

7. Rate Limiting

API Rate Limiting
import rateLimit from 'express-rate-limit'

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100, // 100 requests per window
  message: 'Too many requests'
})

// Apply to routes
app.use('/api/', limiter)
Expensive Operations
// Aggressive rate limiting for searches
const searchLimiter = rateLimit({
  windowMs: 60 * 1000, // 1 minute
  max: 10, // 10 requests per minute
  message: 'Too many search requests'
})

app.use('/api/search', searchLimiter)
Verification Steps
  • Rate limiting on all API endpoints
  • Stricter limits on expensive operations
  • IP-based rate limiting
  • User-based rate limiting (authenticated)

8. Sensitive Data Exposure

Logging
// FAIL: WRONG: Logging sensitive data
console.log('User login:', { email, password })
console.log('Payment:', { cardNumber, cvv })

// PASS: CORRECT: Redact sensitive data
console.log('User login:', { email, userId })
console.log('Payment:', { last4: card.last4, userId })
Error Messages
// FAIL: WRONG: Exposing internal details
catch (error) {
  return NextResponse.json(
    { error: error.message, stack: error.stack },
    { status: 500 }
  )
}

// PASS: CORRECT: Generic error messages
catch (error) {
  console.error('Internal error:', error)
  return NextResponse.json(
    { error: 'An error occurred. Please try again.' },
    { status: 500 }
  )
}
Verification Steps
  • No passwords, tokens, or secrets in logs
  • Error messages generic for users
  • Detailed errors only in server logs
  • No stack traces exposed to users

9. Blockchain Security (Solana)

Wallet Verification
import { verify } from '@solana/web3.js'

async function verifyWalletOwnership(
  publicKey: string,
  signature: string,
  message: string
) {
  try {
    const isValid = verify(
      Buffer.from(message),
      Buffer.from(signature, 'base64'),
      Buffer.from(publicKey, 'base64')
    )
    return isValid
  } catch (error) {
    return false
  }
}
Transaction Verification
async function verifyTransaction(transaction: Transaction) {
  // Verify recipient
  if (transaction.to !== expectedRecipient) {
    throw new Error('Invalid recipient')
  }

  // Verify amount
  if (transaction.amount > maxAmount) {
    throw new Error('Amount exceeds limit')
  }

  // Verify user has sufficient balance
  const balance = await getBalance(transaction.from)
  if (balance < transaction.amount) {
    throw new Error('Insufficient balance')
  }

  return true
}
Verification Steps
  • Wallet signatures verified
  • Transaction details validated
  • Balance checks before transactions
  • No blind transaction signing

10. Dependency Security

Regular Updates
# Check for vulnerabilities
npm audit

# Fix automatically fixable issues (mutates the lockfile — review the diff before committing)
npm audit fix

# Update dependencies
npm update

# Check for outdated packages
npm outdated
Lock Files
# ALWAYS commit lock files
git add package-lock.json

# Use in CI/CD for reproducible builds
npm ci  # Instead of npm install
Verification Steps
  • Dependencies up to date
  • No known vulnerabilities (npm audit clean)
  • Lock files committed
  • Scheduled dependency review with a vulnerability scan (npm audit / pip-audit in CI); enabling Dependabot is an approval-gated decision, not an automatic default
  • Regular security updates

Security Testing

Automated Security Tests

// Test authentication
test('requires authentication', async () => {
  const response = await fetch('/api/protected')
  expect(response.status).toBe(401)
})

// Test authorization
test('requires admin role', async () => {
  const response = await fetch('/api/admin', {
    headers: { Authorization: `Bearer ${userToken}` }
  })
  expect(response.status).toBe(403)
})

// Test input validation
test('rejects invalid input', async () => {
  const response = await fetch('/api/users', {
    method: 'POST',
    body: JSON.stringify({ email: 'not-an-email' })
  })
  expect(response.status).toBe(400)
})

// Test rate limiting
test('enforces rate limits', async () => {
  const requests = Array(101).fill(null).map(() =>
    fetch('/api/endpoint')
  )

  const responses = await Promise.all(requests)
  const tooManyRequests = responses.filter(r => r.status === 429)

  expect(tooManyRequests.length).toBeGreaterThan(0)
})

Pre-Deployment Security Checklist

Before ANY production deployment:

  • Secrets: No hardcoded secrets, all in env vars
  • Input Validation: All user inputs validated
  • SQL Injection: All queries parameterized
  • XSS: User content sanitized
  • CSRF: Protection enabled
  • Authentication: Proper token handling
  • Authorization: Role checks in place
  • Rate Limiting: Enabled on all endpoints
  • HTTPS: Enforced in production
  • Security Headers: CSP, X-Frame-Options configured
  • Error Handling: No sensitive data in errors
  • Logging: No sensitive data logged
  • Dependencies: Up to date, no vulnerabilities
  • Row Level Security: Enabled in Supabase
  • CORS: Properly configured
  • File Uploads: Validated (size, type)
  • Wallet Signatures: Verified (if blockchain)

Resources


Remember: Security is not optional. One vulnerability can compromise the entire platform. When in doubt, err on the side of caution.


OAuth 2.1 / PKCE

  • Mandate PKCE for all authorization code flows (S256 code challenge)
  • Prohibit Implicit Grant: removed in OAuth 2.1; use authorization code + PKCE instead
  • Prohibit ROPC (Resource Owner Password Credentials): no exceptions
  • Refresh Token Rotation: issue a new refresh token on every use; invalidate the old one immediately
  • Access token lifetime: maximum 15 minutes

JWT Validation Checklist

Always validate:

  • alg claim: explicitly reject none algorithm: configure allowed algorithms allowlist
  • exp: token must not be expired
  • iss: must match expected issuer exactly
  • aud: must match expected audience
import jwt

def decode_token(token: str) -> dict:
    return jwt.decode(
        token,
        public_key,
        algorithms=["RS256"],  # Explicit allowlist — never use algorithms=["*"]
        options={"require": ["exp", "iss", "aud"]},
        audience="my-api",
        issuer="https://auth.example.com",
    )

mTLS, Service-to-Service

For internal microservice communication, enforce mutual TLS:

  • Both client and server present certificates
  • Use a private CA for internal service certificates
  • Short certificate lifetimes (< 24h) via cert-manager or Vault PKI

Required Security Headers

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; frame-ancestors 'none'
Permissions-Policy: camera=(), microphone=(), geolocation=()
Referrer-Policy: strict-origin-when-cross-origin
X-Content-Type-Options: nosniff
X-Frame-Options: DENY

Zero Trust Architecture

Principles:

  • Never trust, always verify: no implicit trust based on network location
  • Every request must be authenticated and authorized, even between internal services
  • Network policies: default-deny; explicit allow rules for required communication paths
  • Short-lived credentials: rotate tokens, certificates, and secrets automatically
  • Least privilege: service accounts have only the permissions they need

Supply Chain Security

  • Generate SBOM (Software Bill of Materials) for every release (CycloneDX or SPDX format)
  • Sign container images with cosign (Sigstore) on every production push
  • Pin all dependencies to exact versions in lock files; prohibit unpinned ranges in production
  • Block CI on CRITICAL/HIGH CVEs with available fixes (Trivy, Grype, npm audit)

Audit Logging Requirements

Every security-relevant event must produce an immutable audit log entry with:

  • timestamp (UTC ISO 8601)
  • actor (user ID or service account)
  • action (what was done)
  • resource (what was acted upon)
  • outcome (success/failure)
  • ip_address and user_agent for user-initiated actions

Rules:

  • Write to a write-only log sink (append-only storage, separate account)
  • Retain for minimum 12 months
  • Never expose raw audit logs to end users

Privacy by Design

  • Data minimization: collect only what is strictly necessary
  • Legal basis: document the legal basis (consent, legitimate interest, etc.) for each data category
  • Right to erasure: implement within 30 days of request
  • DPIA (Data Protection Impact Assessment): required before introducing a feature that processes sensitive personal data at scale
  • Pseudonymization in non-production: never use real PII in dev/staging environments

Encryption at Rest

  • Symmetric encryption: AES-256-GCM for field-level encryption
  • Asymmetric: RSA-4096 or ECDSA P-384 for key wrapping
  • KMS/HSM for cryptographic key management: never store master keys in application config
  • Rotate encryption keys annually or after suspected compromise

SAST / DAST Pipeline

  • SAST: run on every PR (Semgrep, SonarQube, or Bandit for Python)
  • DAST: run weekly or before every major release using OWASP ZAP against a staging environment
  • Dependency scanning: npm audit, pip-audit, trivy fs on every PR

What ships with it: 1 file

9.9 KB alongside SKILL.md

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.