security-hardening

Name: security-hardening
Author: DevelopersGlobal

64stars10forks

How to install security-hardening?

developersglobal/ai-agent-skills/security-hardening

$npx -y skills add DevelopersGlobal/ai-agent-skills --skill security-hardening

Installs into the current project.

Summary

Applies OWASP Top 10, secrets management, and least-privilege principles before any code ships. Security is a build step, not an afterthought.

Files · 1

View on GitHub

SKILL.md

1	## Overview
2
3	Security vulnerabilities are almost always cheaper to prevent than to remediate. This skill embeds security review as a required gate in the development workflow — not a separate audit that happens later (and often never).
4
5	## When to Use
6
7	- Before any code involving user input
8	- Before any code touching authentication, authorization, or sessions
9	- Before any API endpoint is created or modified
10	- Before any code that handles secrets, credentials, or PII
11	- Before any code that makes outbound network requests
12
13	## Process
14
15	### Step 1: Threat Model the Change
16
17	1. Ask: Who are the attackers? What are they trying to achieve?
18	2. Identify all trust boundaries in the code:
19	- Where does user-controlled data enter the system?
20	- Where does that data flow?
21	- Where is it stored or transmitted?
22	3. For each trust boundary, name the top 3 attack vectors.
23
24	Verify: You can name at least one realistic attack scenario for this code.
25
26	### Step 2: Apply OWASP Top 10 Checklist
27
28	4. For each applicable item, confirm it is addressed:
29
30	\| OWASP Item \| Check \|
31	\|------------\|-------\|
32	\| A01 Broken Access Control \| Authorization checked at every endpoint? Principle of least privilege applied? \|
33	\| A02 Cryptographic Failures \| No plaintext PII/secrets? Using modern algorithms (AES-256, SHA-256+)? TLS everywhere? \|
34	\| A03 Injection \| All user input parameterized/sanitized? No raw SQL/shell construction? \|
35	\| A04 Insecure Design \| Threat model done? Secure defaults? Fail closed (not open)? \|
36	\| A05 Security Misconfiguration \| No default credentials? Unnecessary features disabled? Error messages don't leak internals? \|
37	\| A06 Vulnerable Components \| Dependencies up to date? Known CVEs checked? \|
38	\| A07 Auth Failures \| Brute-force protection? Session management correct? MFA available? \|
39	\| A08 Software Integrity \| Dependencies verified? Supply chain integrity? \|
40	\| A09 Logging Failures \| Security events logged? No secrets in logs? Logs protected from tampering? \|
41	\| A10 SSRF \| Outbound requests validated? Internal IPs blocked from user-controlled URLs? \|
42
43	Verify: Each applicable item is either addressed or explicitly accepted as a known risk.
44
45	### Step 3: Secrets Management
46
47	5. No hardcoded secrets — ever. Not even in dev/test code.
48	6. Secrets are stored in: environment variables, secrets manager (Vault, AWS Secrets Manager, etc.), or encrypted config.
49	7. Secrets are never logged, printed, or included in error messages.
50	8. Secrets are never committed to git (check `.gitignore` and use pre-commit hooks).
51
52	Verify: `git grep -i 'password\\|secret\\|key\\|token'` returns no hardcoded values in code.
53
54	### Step 4: Input Validation
55
56	9. Every piece of external input is validated:
57	- Type check
58	- Length/size limits
59	- Allowlist of expected values (not blocklist)
60	- Reject and log unexpected input — never silently ignore
61	10. User-controlled data is never concatenated into SQL, shell commands, HTML, or file paths without proper escaping/parameterization.
62
63	Verify: All external input has explicit validation with reject-by-default behavior.
64
65	### Step 5: Least Privilege
66
67	11. Database connections use the minimum required permissions.
68	12. API tokens have the minimum required scopes.
69	13. Service accounts cannot access resources they don't need.
70	14. Default deny — access must be explicitly granted, not implicitly inherited.
71
72	Verify: List every permission granted by this code. Is each one required?
73
74	## Common Rationalizations (and Rebuttals)
75
76	\| Excuse \| Rebuttal \|
77	\|--------\|----------\|
78	\| "It's internal only" \| Internal services get breached too. Zero-trust applies internally. \|
79	\| "We'll add auth later" \| Auth bolted on later is always broken. Design it in from the start. \|
80	\| "The input is from our own frontend" \| Attackers don't use your frontend. Validate on the server, always. \|
81	\| "It's a dev environment" \| Dev environments get credentials from prod. Treat them accordingly. \|
82	\| "The secret is in a config file, not code" \| Is the config file in git? Is it world-readable? Config files are not safe. \|
83
84	## Red Flags
85
86	- User input directly interpolated into queries or commands
87	- Authentication middleware that can be bypassed
88	- Error messages that include stack traces or SQL queries
89	- API keys or passwords in source code or comments
90	- Missing authorization check on any endpoint
91	- HTTP used instead of HTTPS for any sensitive data
92
93	## Verification
94
95	- [ ] OWASP Top 10 checklist reviewed for applicable items
96	- [ ] No hardcoded secrets (`git grep` clean)
97	- [ ] All external input validated (type, length, allowlist)
98	- [ ] No raw SQL/shell from user input
99	- [ ] Least privilege applied to all credentials
100	- [ ] Sec

People who liked this also viewed

6 picks

Type

entra-app-registrationGuides Microsoft Entra ID app registration, OAuth 2.0 authentication, and MSAL integration. USE FOR: create app registration, register Azure AD app, configure OAuth, set up authentication, add API perSkillsJul 2026471k1.3k
azure-complianceRun Azure compliance and security audits with azqr plus Key Vault expiration checks. Covers best-practice assessment, resource review, policy/compliance validation, and security posture checks. WHEN: SkillsJul 2026470k1.3k
azure-rbacOfficial agent plugin providing skills and MCP server configurations for Azure scenarios.SkillsJul 2026466k1.3k
better-auth-best-practicesAgent skill from better-auth/skillsSkillsJul 202678k203
firebase-security-rules-auditorA skill to evaluate how secure Firestore security rules are. Use this when Firestore security rules are updated to ensure that the generated rules are extremely secure and robust.SkillsJul 202676k386
audit-websiteAudit a website with the squirrelscan CLI and fix the findings in code. Runs SEO, performance, security, technical, content, accessibility, and 15 other rule categories (260+ rules), returns an LLM-opSkillsJul 202665k85

security-hardening

64stars10forks

View on GitHub

How to install security-hardening?

developersglobal/ai-agent-skills/security-hardening

$npx -y skills add DevelopersGlobal/ai-agent-skills --skill security-hardening

Installs into the current project.

Summary

Applies OWASP Top 10, secrets management, and least-privilege principles before any code ships. Security is a build step, not an afterthought.

Files · 1

View on GitHub

SKILL.md

1	## Overview
2
3	Security vulnerabilities are almost always cheaper to prevent than to remediate. This skill embeds security review as a required gate in the development workflow — not a separate audit that happens later (and often never).
4
5	## When to Use
6
7	- Before any code involving user input
8	- Before any code touching authentication, authorization, or sessions
9	- Before any API endpoint is created or modified
10	- Before any code that handles secrets, credentials, or PII
11	- Before any code that makes outbound network requests
12
13	## Process
14
15	### Step 1: Threat Model the Change
16
17	1. Ask: Who are the attackers? What are they trying to achieve?
18	2. Identify all trust boundaries in the code:
19	- Where does user-controlled data enter the system?
20	- Where does that data flow?
21	- Where is it stored or transmitted?
22	3. For each trust boundary, name the top 3 attack vectors.
23
24	Verify: You can name at least one realistic attack scenario for this code.
25
26	### Step 2: Apply OWASP Top 10 Checklist
27
28	4. For each applicable item, confirm it is addressed:
29
30	\| OWASP Item \| Check \|
31	\|------------\|-------\|
32	\| A01 Broken Access Control \| Authorization checked at every endpoint? Principle of least privilege applied? \|
33	\| A02 Cryptographic Failures \| No plaintext PII/secrets? Using modern algorithms (AES-256, SHA-256+)? TLS everywhere? \|
34	\| A03 Injection \| All user input parameterized/sanitized? No raw SQL/shell construction? \|
35	\| A04 Insecure Design \| Threat model done? Secure defaults? Fail closed (not open)? \|
36	\| A05 Security Misconfiguration \| No default credentials? Unnecessary features disabled? Error messages don't leak internals? \|
37	\| A06 Vulnerable Components \| Dependencies up to date? Known CVEs checked? \|
38	\| A07 Auth Failures \| Brute-force protection? Session management correct? MFA available? \|
39	\| A08 Software Integrity \| Dependencies verified? Supply chain integrity? \|
40	\| A09 Logging Failures \| Security events logged? No secrets in logs? Logs protected from tampering? \|
41	\| A10 SSRF \| Outbound requests validated? Internal IPs blocked from user-controlled URLs? \|
42
43	Verify: Each applicable item is either addressed or explicitly accepted as a known risk.
44
45	### Step 3: Secrets Management
46
47	5. No hardcoded secrets — ever. Not even in dev/test code.
48	6. Secrets are stored in: environment variables, secrets manager (Vault, AWS Secrets Manager, etc.), or encrypted config.
49	7. Secrets are never logged, printed, or included in error messages.
50	8. Secrets are never committed to git (check `.gitignore` and use pre-commit hooks).
51
52	Verify: `git grep -i 'password\\|secret\\|key\\|token'` returns no hardcoded values in code.
53
54	### Step 4: Input Validation
55
56	9. Every piece of external input is validated:
57	- Type check
58	- Length/size limits
59	- Allowlist of expected values (not blocklist)
60	- Reject and log unexpected input — never silently ignore
61	10. User-controlled data is never concatenated into SQL, shell commands, HTML, or file paths without proper escaping/parameterization.
62
63	Verify: All external input has explicit validation with reject-by-default behavior.
64
65	### Step 5: Least Privilege
66
67	11. Database connections use the minimum required permissions.
68	12. API tokens have the minimum required scopes.
69	13. Service accounts cannot access resources they don't need.
70	14. Default deny — access must be explicitly granted, not implicitly inherited.
71
72	Verify: List every permission granted by this code. Is each one required?
73
74	## Common Rationalizations (and Rebuttals)
75
76	\| Excuse \| Rebuttal \|
77	\|--------\|----------\|
78	\| "It's internal only" \| Internal services get breached too. Zero-trust applies internally. \|
79	\| "We'll add auth later" \| Auth bolted on later is always broken. Design it in from the start. \|
80	\| "The input is from our own frontend" \| Attackers don't use your frontend. Validate on the server, always. \|
81	\| "It's a dev environment" \| Dev environments get credentials from prod. Treat them accordingly. \|
82	\| "The secret is in a config file, not code" \| Is the config file in git? Is it world-readable? Config files are not safe. \|
83
84	## Red Flags
85
86	- User input directly interpolated into queries or commands
87	- Authentication middleware that can be bypassed
88	- Error messages that include stack traces or SQL queries
89	- API keys or passwords in source code or comments
90	- Missing authorization check on any endpoint
91	- HTTP used instead of HTTPS for any sensitive data
92
93	## Verification
94
95	- [ ] OWASP Top 10 checklist reviewed for applicable items
96	- [ ] No hardcoded secrets (`git grep` clean)
97	- [ ] All external input validated (type, length, allowlist)
98	- [ ] No raw SQL/shell from user input
99	- [ ] Least privilege applied to all credentials
100	- [ ] Sec

People who liked this also viewed

6 picks

Type