security-and-hardening

Name: security-and-hardening
Author: addyosmani

15kinstalls8.6kforks

How to install security-and-hardening?

addyosmani/agent-skills/security-and-hardening

$npx -y skills add addyosmani/agent-skills --skill security-and-hardening

Installs into the current project.

Summary

Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services.

Files · 1

View on GitHub

SKILL.md

1	# Security and Hardening
2
3	## Overview
4
5	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.
6
7	## When to Use
8
9	- Building anything that accepts user input
10	- Implementing authentication or authorization
11	- Storing or transmitting sensitive data
12	- Integrating with external APIs or services
13	- Adding file uploads, webhooks, or callbacks
14	- Handling payment or PII data
15
16	## Process: Threat Model First
17
18	Controls bolted on without a threat model are guesses. Before hardening, spend five minutes thinking like an attacker:
19
20	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. Every boundary is attack surface.
21	2. Name the assets. What's worth stealing or breaking? Credentials, PII, payment data, admin actions, money movement.
22	3. Run STRIDE over each boundary — a quick lens, not a ceremony:
23
24	\| Threat \| Ask \| Typical mitigation \|
25	\|---\|---\|---\|
26	\| Spoofing \| Can someone impersonate a user/service? \| Authentication, signature verification \|
27	\| Tampering \| Can data be altered in transit or at rest? \| Integrity checks, parameterized queries, HTTPS \|
28	\| Repudiation \| Can an action be denied later? \| Audit logging of security events \|
29	\| Information disclosure \| Can data leak? \| Encryption, field allowlists, generic errors \|
30	\| Denial of service \| Can it be overwhelmed? \| Rate limiting, input size caps, timeouts \|
31	\| Elevation of privilege \| Can a user gain rights they shouldn't? \| Authorization checks, least privilege \|
32
33	4. Write abuse cases next to use cases. For each feature, ask "how would I misuse this?" — then make that your first test.
34
35	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.
36
37	## The Three-Tier Boundary System
38
39	### Always Do (No Exceptions)
40
41	- Validate all external input at the system boundary (API routes, form handlers)
42	- Parameterize all database queries — never concatenate user input into SQL
43	- Encode output to prevent XSS (use framework auto-escaping, don't bypass it)
44	- Use HTTPS for all external communication
45	- Hash passwords with bcrypt/scrypt/argon2 (never store plaintext)
46	- Set security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
47	- Use httpOnly, secure, sameSite cookies for sessions
48	- Run the detected package manager's native audit against the committed lockfile before every release
49
50	### Ask First (Requires Human Approval)
51
52	- Adding new authentication flows or changing auth logic
53	- Storing new categories of sensitive data (PII, payment info)
54	- Adding new external service integrations
55	- Changing CORS configuration
56	- Adding file upload handlers
57	- Modifying rate limiting or throttling
58	- Granting elevated permissions or roles
59
60	### Never Do
61
62	- Never commit secrets to version control (API keys, passwords, tokens)
63	- Never log sensitive data (passwords, tokens, full credit card numbers)
64	- Never trust client-side validation as a security boundary
65	- Never disable security headers for convenience
66	- Never use `eval()` or `innerHTML` with user-provided data
67	- Never store sessions in client-accessible storage (localStorage for auth tokens)
68	- Never expose stack traces or internal error details to users
69
70	## OWASP Top 10 Prevention Patterns
71
72	These are prevention patterns, not a ranking. For the 2021 ordering, see the quick-reference table in `references/security-checklist.md`.
73
74	### Injection (SQL, NoSQL, OS Command)
75
76	```typescript
77	// BAD: SQL injection via string concatenation
78	const query = `SELECT * FROM users WHERE id = '${userId}'`;
79
80	// GOOD: Parameterized query
81	const user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);
82
83	// GOOD: ORM with parameterized input
84	const user = await prisma.user.findUnique({ where: { id: userId } });
85	```
86
87	### Broken Authentication
88
89	```typescript
90	// Password hashing
91	import { hash, compare } from 'bcrypt';
92
93	const SALT_ROUNDS = 12;
94	const hashedPassword = await hash(plaintext, SALT_ROUNDS);
95	const isValid = await compare(plaintext, hashedPassword);
96
97	// Session management
98	app.use(session({
99	secret: process.env.SESSION_SECRET, // From environment, not code
100	resave: false,
101	saveUninitialized: false,
102	cookie: {
103	httpOnly: true, // Not accessible via JavaScript
104	secure: true, // HTTPS o

People who liked this also viewed

6 picks

Type

security-and-hardening

15kinstalls8.6kforks

View on GitHub

How to install security-and-hardening?

addyosmani/agent-skills/security-and-hardening

$npx -y skills add addyosmani/agent-skills --skill security-and-hardening

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Security and Hardening
2
3	## Overview
4
5	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.
6
7	## When to Use
8
9	- Building anything that accepts user input
10	- Implementing authentication or authorization
11	- Storing or transmitting sensitive data
12	- Integrating with external APIs or services
13	- Adding file uploads, webhooks, or callbacks
14	- Handling payment or PII data
15
16	## Process: Threat Model First
17
18	Controls bolted on without a threat model are guesses. Before hardening, spend five minutes thinking like an attacker:
19
20	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. Every boundary is attack surface.
21	2. Name the assets. What's worth stealing or breaking? Credentials, PII, payment data, admin actions, money movement.
22	3. Run STRIDE over each boundary — a quick lens, not a ceremony:
23
24	\| Threat \| Ask \| Typical mitigation \|
25	\|---\|---\|---\|
26	\| Spoofing \| Can someone impersonate a user/service? \| Authentication, signature verification \|
27	\| Tampering \| Can data be altered in transit or at rest? \| Integrity checks, parameterized queries, HTTPS \|
28	\| Repudiation \| Can an action be denied later? \| Audit logging of security events \|
29	\| Information disclosure \| Can data leak? \| Encryption, field allowlists, generic errors \|
30	\| Denial of service \| Can it be overwhelmed? \| Rate limiting, input size caps, timeouts \|
31	\| Elevation of privilege \| Can a user gain rights they shouldn't? \| Authorization checks, least privilege \|
32
33	4. Write abuse cases next to use cases. For each feature, ask "how would I misuse this?" — then make that your first test.
34
35	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.
36
37	## The Three-Tier Boundary System
38
39	### Always Do (No Exceptions)
40
41	- Validate all external input at the system boundary (API routes, form handlers)
42	- Parameterize all database queries — never concatenate user input into SQL
43	- Encode output to prevent XSS (use framework auto-escaping, don't bypass it)
44	- Use HTTPS for all external communication
45	- Hash passwords with bcrypt/scrypt/argon2 (never store plaintext)
46	- Set security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
47	- Use httpOnly, secure, sameSite cookies for sessions
48	- Run the detected package manager's native audit against the committed lockfile before every release
49
50	### Ask First (Requires Human Approval)
51
52	- Adding new authentication flows or changing auth logic
53	- Storing new categories of sensitive data (PII, payment info)
54	- Adding new external service integrations
55	- Changing CORS configuration
56	- Adding file upload handlers
57	- Modifying rate limiting or throttling
58	- Granting elevated permissions or roles
59
60	### Never Do
61
62	- Never commit secrets to version control (API keys, passwords, tokens)
63	- Never log sensitive data (passwords, tokens, full credit card numbers)
64	- Never trust client-side validation as a security boundary
65	- Never disable security headers for convenience
66	- Never use `eval()` or `innerHTML` with user-provided data
67	- Never store sessions in client-accessible storage (localStorage for auth tokens)
68	- Never expose stack traces or internal error details to users
69
70	## OWASP Top 10 Prevention Patterns
71
72	These are prevention patterns, not a ranking. For the 2021 ordering, see the quick-reference table in `references/security-checklist.md`.
73
74	### Injection (SQL, NoSQL, OS Command)
75
76	```typescript
77	// BAD: SQL injection via string concatenation
78	const query = `SELECT * FROM users WHERE id = '${userId}'`;
79
80	// GOOD: Parameterized query
81	const user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);
82
83	// GOOD: ORM with parameterized input
84	const user = await prisma.user.findUnique({ where: { id: userId } });
85	```
86
87	### Broken Authentication
88
89	```typescript
90	// Password hashing
91	import { hash, compare } from 'bcrypt';
92
93	const SALT_ROUNDS = 12;
94	const hashedPassword = await hash(plaintext, SALT_ROUNDS);
95	const isValid = await compare(plaintext, hashedPassword);
96
97	// Session management
98	app.use(session({
99	secret: process.env.SESSION_SECRET, // From environment, not code
100	resave: false,
101	saveUninitialized: false,
102	cookie: {
103	httpOnly: true, // Not accessible via JavaScript
104	secure: true, // HTTPS o

People who liked this also viewed

6 picks

Type