security

Name: security
Author: krzysztofsurdy

47installs1forks

How to install security?

krzysztofsurdy/code-virtuoso/security

$npx -y skills add krzysztofsurdy/code-virtuoso --skill security

Installs into the current project.

Summary

Application security principles and OWASP Top 10 for building secure web applications. Use when the user asks to review code for security vulnerabilities, implement authentication or authorization, handle secrets or API keys, configure security headers, prevent injection attacks

Files · 1

View on GitHub

SKILL.md

1	# Security
2
3	Security is not a feature — it is a property of every feature. Every endpoint, every form, every data flow, every integration point must be designed with security in mind from the start. Bolting security on after the fact is expensive, error-prone, and often incomplete.
4
5	This skill provides stack-agnostic guidance for building secure applications. It covers the OWASP Top 10, input validation, authentication and authorization patterns, data protection, secrets management, security headers, and common antipatterns.
6
7	## When to Use
8
9	Consult this skill when:
10
11	- Designing a new feature that handles user input, authentication, or sensitive data
12	- Reviewing code for security concerns
13	- Implementing authentication or authorization flows
14	- Handling secrets, API keys, or credentials
15	- Configuring HTTP security headers
16	- Assessing whether a dependency or design choice introduces risk
17	- Preparing for a security audit or penetration test
18	- Responding to a security incident or vulnerability report
19
20	## OWASP Top 10
21
22	The OWASP Top 10 (2021 edition) represents the most critical security risks to web applications. Use this as a starting checklist — not an exhaustive list.
23
24	\| # \| Vulnerability \| What It Is \| Primary Defense \|
25	\|---\|---\|---\|---\|
26	\| A01 \| Broken Access Control \| Users act outside intended permissions \| Deny by default, enforce server-side \| [reference](references/owasp-top-10.md) \|
27	\| A02 \| Cryptographic Failures \| Sensitive data exposed due to weak/missing crypto \| Use strong algorithms, encrypt in transit and at rest \| [reference](references/owasp-top-10.md) \|
28	\| A03 \| Injection \| Untrusted data sent to interpreter as part of a command/query \| Parameterized queries, input validation \| [reference](references/owasp-top-10.md) \|
29	\| A04 \| Insecure Design \| Missing or ineffective security controls by design \| Threat modeling, secure design patterns \| [reference](references/owasp-top-10.md) \|
30	\| A05 \| Security Misconfiguration \| Insecure default configs, incomplete setup \| Hardened defaults, automated config validation \| [reference](references/owasp-top-10.md) \|
31	\| A06 \| Vulnerable Components \| Using components with known vulnerabilities \| Dependency scanning, timely updates \| [reference](references/owasp-top-10.md) \|
32	\| A07 \| Auth Failures \| Broken authentication/identification \| MFA, rate limiting, secure password storage \| [reference](references/owasp-top-10.md) \|
33	\| A08 \| Integrity Failures \| Code/data integrity not verified \| Signed updates, CI/CD integrity checks \| [reference](references/owasp-top-10.md) \|
34	\| A09 \| Logging Failures \| Insufficient logging and monitoring \| Log security events, set up alerting \| [reference](references/owasp-top-10.md) \|
35	\| A10 \| SSRF \| Server tricked into making unintended requests \| Allowlist destinations, sanitize URLs \| [reference](references/owasp-top-10.md) \|
36
37	## Input Validation
38
39	Input validation is the first line of defense. Validate at every system boundary — not just at the UI.
40
41	Core principles:
42
43	- Validate on the server — client-side validation is a UX convenience, not a security control
44	- Allowlist over denylist — define what is acceptable rather than trying to block what is dangerous
45	- Validate type, length, format, and range — a "name" field should not accept 10MB of data or contain control characters
46	- Reject unexpected input — fail closed, do not attempt to "clean" malicious input and proceed
47	- Canonicalize before validation — normalize Unicode, decode URL encoding, resolve path traversals before checking
48
49	Type coercion dangers:
50
51	Loose type comparisons can bypass security checks. A string "0" might equal integer 0 or boolean false depending on the language. Always use strict comparison operators and explicit type casting.
52
53	Parameterized queries:
54
55	Never concatenate user input into SQL, LDAP, or OS commands. Always use parameterized queries or prepared statements. This applies to ORMs too — raw query methods bypass ORM protections. See [secure coding reference](references/secure-coding.md) for details.
56
57	## Authentication Patterns
58
59	Authentication verifies identity — "who are you?" See [auth patterns reference](references/auth-patterns.md) for detailed guidance.
60
61	Password hashing:
62
63	- Use bcrypt, scrypt, or Argon2id — never MD5, SHA-1, or SHA-256 alone for passwords
64	- Salts must be unique per password and generated by the hashing library
65	- Never store plain-text passwor

People who liked this also viewed

6 picks

Type

security

47installs1forks

View on GitHub

How to install security?

krzysztofsurdy/code-virtuoso/security

$npx -y skills add krzysztofsurdy/code-virtuoso --skill security

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Security
2
3	Security is not a feature — it is a property of every feature. Every endpoint, every form, every data flow, every integration point must be designed with security in mind from the start. Bolting security on after the fact is expensive, error-prone, and often incomplete.
4
5	This skill provides stack-agnostic guidance for building secure applications. It covers the OWASP Top 10, input validation, authentication and authorization patterns, data protection, secrets management, security headers, and common antipatterns.
6
7	## When to Use
8
9	Consult this skill when:
10
11	- Designing a new feature that handles user input, authentication, or sensitive data
12	- Reviewing code for security concerns
13	- Implementing authentication or authorization flows
14	- Handling secrets, API keys, or credentials
15	- Configuring HTTP security headers
16	- Assessing whether a dependency or design choice introduces risk
17	- Preparing for a security audit or penetration test
18	- Responding to a security incident or vulnerability report
19
20	## OWASP Top 10
21
22	The OWASP Top 10 (2021 edition) represents the most critical security risks to web applications. Use this as a starting checklist — not an exhaustive list.
23
24	\| # \| Vulnerability \| What It Is \| Primary Defense \|
25	\|---\|---\|---\|---\|
26	\| A01 \| Broken Access Control \| Users act outside intended permissions \| Deny by default, enforce server-side \| [reference](references/owasp-top-10.md) \|
27	\| A02 \| Cryptographic Failures \| Sensitive data exposed due to weak/missing crypto \| Use strong algorithms, encrypt in transit and at rest \| [reference](references/owasp-top-10.md) \|
28	\| A03 \| Injection \| Untrusted data sent to interpreter as part of a command/query \| Parameterized queries, input validation \| [reference](references/owasp-top-10.md) \|
29	\| A04 \| Insecure Design \| Missing or ineffective security controls by design \| Threat modeling, secure design patterns \| [reference](references/owasp-top-10.md) \|
30	\| A05 \| Security Misconfiguration \| Insecure default configs, incomplete setup \| Hardened defaults, automated config validation \| [reference](references/owasp-top-10.md) \|
31	\| A06 \| Vulnerable Components \| Using components with known vulnerabilities \| Dependency scanning, timely updates \| [reference](references/owasp-top-10.md) \|
32	\| A07 \| Auth Failures \| Broken authentication/identification \| MFA, rate limiting, secure password storage \| [reference](references/owasp-top-10.md) \|
33	\| A08 \| Integrity Failures \| Code/data integrity not verified \| Signed updates, CI/CD integrity checks \| [reference](references/owasp-top-10.md) \|
34	\| A09 \| Logging Failures \| Insufficient logging and monitoring \| Log security events, set up alerting \| [reference](references/owasp-top-10.md) \|
35	\| A10 \| SSRF \| Server tricked into making unintended requests \| Allowlist destinations, sanitize URLs \| [reference](references/owasp-top-10.md) \|
36
37	## Input Validation
38
39	Input validation is the first line of defense. Validate at every system boundary — not just at the UI.
40
41	Core principles:
42
43	- Validate on the server — client-side validation is a UX convenience, not a security control
44	- Allowlist over denylist — define what is acceptable rather than trying to block what is dangerous
45	- Validate type, length, format, and range — a "name" field should not accept 10MB of data or contain control characters
46	- Reject unexpected input — fail closed, do not attempt to "clean" malicious input and proceed
47	- Canonicalize before validation — normalize Unicode, decode URL encoding, resolve path traversals before checking
48
49	Type coercion dangers:
50
51	Loose type comparisons can bypass security checks. A string "0" might equal integer 0 or boolean false depending on the language. Always use strict comparison operators and explicit type casting.
52
53	Parameterized queries:
54
55	Never concatenate user input into SQL, LDAP, or OS commands. Always use parameterized queries or prepared statements. This applies to ORMs too — raw query methods bypass ORM protections. See [secure coding reference](references/secure-coding.md) for details.
56
57	## Authentication Patterns
58
59	Authentication verifies identity — "who are you?" See [auth patterns reference](references/auth-patterns.md) for detailed guidance.
60
61	Password hashing:
62
63	- Use bcrypt, scrypt, or Argon2id — never MD5, SHA-1, or SHA-256 alone for passwords
64	- Salts must be unique per password and generated by the hashing library
65	- Never store plain-text passwor

People who liked this also viewed

6 picks

Type