addyosmani/agent-skills1 file

Security And Hardening

Hardens code against vulnerabilities. Use when auditing an input handler for vulnerabilities, when handling user input, authentication, data storage, or external integrations, or when checking a login flow is safe against the OWASP Top Ten. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services. Use when auditing dependencies for known vulnerabilities, triaging package-manager audit findings, or assessing supply-chain risk in a new package. Use when personal data or privacy compliance (GDPR, CCPA) is involved.

Specification
Skill ID
addyosmani/agent-skills/security-and-hardening
Publisher
addyosmani
Repository
agent-skills
Installs
624
Files
1
Synced
Sep 16, 2026
How to use it

Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.

addyosmani/agent-skills/security-and-hardeningInstalls these files
  • SKILL.md

What this skill tells the agent

Security and Hardening

Overview

Security-first development practices for web applications. Treat every external input as hostile, every secret as sacred, and every authorization check as mandatory. Security isn't a phase — it's a constraint on every line of code that touches user data, authentication, or external systems.

When to Use

  • Building anything that accepts user input
  • Implementing authentication or authorization
  • Storing or transmitting sensitive data
  • Integrating with external APIs or services
  • Adding file uploads, webhooks, or callbacks
  • Handling payment or PII data

Process: Threat Model First

Controls bolted on without a threat model are guesses. Before hardening, spend five minutes thinking like an attacker:

  1. Map the trust boundaries. Where does untrusted data cross into your system? HTTP requests, form fields, file uploads, webhooks, third-party APIs, message queues, and LLM output — plus the local values that look internal because the OS handed them to you: another process's command line or environment, filenames on a shared volume, a path in a job payload. Trust follows who wrote a value, not which channel delivered it. Every boundary is attack surface.
  2. Name the assets. What's worth stealing or breaking? Credentials, PII, payment data, admin actions, money movement.
  3. Run STRIDE over each boundary — a quick lens, not a ceremony:
ThreatAskTypical mitigation
SpoofingCan someone impersonate a user/service?Authentication, signature verification
TamperingCan data be altered in transit or at rest?Integrity checks, parameterized queries, HTTPS
RepudiationCan an action be denied later?Audit logging of security events
Information disclosureCan data leak?Encryption, field allowlists, generic errors
Denial of serviceCan it be overwhelmed?Rate limiting, input size caps, timeouts
Elevation of privilegeCan a user gain rights they shouldn't?Authorization checks, least privilege
  1. Write abuse cases next to use cases. For each feature, ask "how would I misuse this?" — then make that your first test.

If you can't name the trust boundaries for a feature, you're not ready to secure it. This is OWASP A04: Insecure Design — most breaches begin in design, not code.

The Three-Tier Boundary System

Always Do (No Exceptions)

  • Validate all external input at the system boundary (API routes, form handlers)
  • Parameterize all database queries — never concatenate user input into SQL
  • Encode output to prevent XSS (use framework auto-escaping, don't bypass it)
  • Use HTTPS for all external communication
  • Hash passwords with bcrypt/scrypt/argon2 (never store plaintext)
  • Set security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
  • Use httpOnly, secure, sameSite cookies for sessions
  • Run the detected package manager's native audit against the committed lockfile before every release

Ask First (Requires Human Approval)

  • Adding new authentication flows or changing auth logic
  • Storing new categories of sensitive data (PII, payment info)
  • Adding new external service integrations
  • Changing CORS configuration
  • Adding file upload handlers
  • Modifying rate limiting or throttling
  • Granting elevated permissions or roles

Never Do

  • Never commit secrets to version control (API keys, passwords, tokens)
  • Never log sensitive data (passwords, tokens, full credit card numbers)
  • Never trust client-side validation as a security boundary
  • Never disable security headers for convenience
  • Never use `eval()` or `innerHTML` with user-provided data
  • Never store sessions in client-accessible storage (localStorage for auth tokens)
  • Never expose stack traces or internal error details to users

OWASP Top 10 Prevention Patterns

These are prevention patterns, not a ranking. For the 2021 ordering, see the quick-reference table in ../../references/security-checklist.md.

Injection (SQL, NoSQL, OS Command)

// BAD: SQL injection via string concatenation
const query = `SELECT * FROM users WHERE id = '${userId}'`;

// GOOD: Parameterized query
const user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);

// GOOD: ORM with parameterized input
const user = await prisma.user.findUnique({ where: { id: userId } });

Broken Authentication

// Password hashing
import { hash, compare } from 'bcrypt';

const SALT_ROUNDS = 12;
const hashedPassword = await hash(plaintext, SALT_ROUNDS);
const isValid = await compare(plaintext, hashedPassword);

// Session management
app.use(session({
  secret: process.env.SESSION_SECRET,  // From environment, not code
  resave: false,
  saveUninitialized: false,
  cookie: {
    httpOnly: true,     // Not accessible via JavaScript
    secure: true,       // HTTPS only
    sameSite: 'lax',    // CSRF protection
    maxAge: 24 * 60 * 60 * 1000,  // 24 hours
  },
}));

Cross-Site Scripting (XSS)

// BAD: Rendering user input as HTML
element.innerHTML = userInput;

// GOOD: Use framework auto-escaping (React does this by default)
return <div>{userInput}</div>;

// If you MUST render HTML, sanitize first
import DOMPurify from 'dompurify';
const clean = DOMPurify.sanitize(userInput);

Broken Access Control

// Always check authorization, not just authentication
app.patch('/api/tasks/:id', authenticate, async (req, res) => {
  const task = await taskService.findById(req.params.id);

  // Check that the authenticated user owns this resource
  if (task.ownerId !== req.user.id) {
    return res.status(403).json({
      error: { code: 'FORBIDDEN', message: 'Not authorized to modify this task' }
    });
  }

  // Proceed with update
  const updated = await taskService.update(req.params.id, req.body);
  return res.json(updated);
});

Security Misconfiguration

// Security headers (use helmet for Express)
import helmet from 'helmet';
app.use(helmet());

// Content Security Policy
app.use(helmet.contentSecurityPolicy({
  directives: {
    defaultSrc: ["'self'"],
    scriptSrc: ["'self'"],
    styleSrc: ["'self'", "'unsafe-inline'"],  // Tighten if possible
    imgSrc: ["'self'", 'data:', 'https:'],
    connectSrc: ["'self'"],
  },
}));

// CORS — restrict to known origins
app.use(cors({
  origin: process.env.ALLOWED_ORIGINS?.split(',') || 'http://localhost:3000',
  credentials: true,
}));

Sensitive Data Exposure

// Never return sensitive fields in API responses
function sanitizeUser(user: UserRecord): PublicUser {
  const { passwordHash, resetToken, ...publicFields } = user;
  return publicFields;
}

// Use environment variables for secrets
const API_KEY = process.env.STRIPE_API_KEY;
if (!API_KEY) throw new Error('STRIPE_API_KEY not configured');

Server-Side Request Forgery (SSRF)

Any time the server fetches a URL the user influenced — webhooks, "import from URL", image proxies, link previews — an attacker can aim it at internal services (cloud metadata, localhost, private IPs).

// BAD: fetch whatever the user gives you
await fetch(req.body.webhookUrl);

// GOOD: allowlist scheme + host, reject if ANY resolved IP is private, forbid redirects
import { lookup } from 'node:dns/promises';
import ipaddr from 'ipaddr.js';

const ALLOWED_HOSTS = new Set(['hooks.example.com']);

async function assertSafeUrl(raw: string): Promise<URL> {
  const url = new URL(raw);
  if (url.protocol !== 'https:') throw new Error('https only');
  if (!ALLOWED_HOSTS.has(url.hostname)) throw new Error('host not allowed');
  // Resolve ALL records; a single private/reserved address fails the check.
  const addrs = await lookup(url.hostname, { all: true });
  if (addrs.some((a) => ipaddr.parse(a.address).range() !== 'unicast')) {
    throw new Error('private/reserved IP');
  }