refactor(rules): group focused security rules

This commit is contained in:
fraujulian committed 2026-09-24 21:47:59 +02:00
1 parent 646e552ff1
commit 0bdd5f46b3
10 files changed
+9 -11

No files matched your search

+7
View File
@@ -0,0 +1,7 @@
# API security
* Authenticate and authorize protected endpoints; validate every request payload and identifier.
* Bound request and response sizes, pagination, query results, and expensive operations.
* Apply rate limits where abuse is plausible and keep administrative endpoints separately protected.
* Return only authorized data and never expose stack traces, internal models, or implementation details in API errors.
* Prefer explicit DTOs and schemas over deserializing arbitrary types or executable objects.
+8
View File
@@ -0,0 +1,8 @@
# Authentication and authorization security
* Use established authentication standards and password hashing; never store plaintext or reversibly encrypted passwords.
* Enforce authorization server-side for every sensitive operation and verify resource ownership and tenant boundaries.
* Use least-privilege roles, short-lived sessions or tokens where supported, and invalidate credentials after sensitive account changes.
* Validate token issuer, audience, signature, and expiry before trusting claims.
* Protect authentication and privileged actions against brute force and privilege escalation.
* Test unauthenticated, unauthorized, cross-user, and cross-tenant access paths.
@@ -0,0 +1,6 @@
# Cryptography and secrets security
* Never implement custom cryptographic primitives or use obsolete algorithms.
* Use established libraries, authenticated encryption, secure randomness, and verified signatures and certificates.
* Treat tokens, private keys, connection strings, and credentials as secrets; keep them out of source, URLs, command lines, logs, fixtures, and frontend code.
* Use environment-appropriate secret storage, separate environments, and rotate compromised credentials.
+7
View File
@@ -0,0 +1,7 @@
# Database and data security
* Use parameterized queries or ORM parameter binding; never concatenate untrusted input into SQL.
* Use least-privilege database accounts and protect connection strings.
* Scope tenant-owned queries explicitly and prevent cross-tenant cache, logging, and diagnostic leakage.
* Collect and retain only necessary sensitive data; encrypt it in transit and at rest where appropriate.
* Avoid raw database errors and use transactions where integrity requires atomicity.
@@ -0,0 +1,6 @@
# File and process security
* Validate filenames, content, sizes, and paths; prevent traversal, zip-slip, and unsafe symbolic-link use.
* Restrict access to intended directories and do not execute uploaded or untrusted files.
* Do not concatenate untrusted input into shell commands; prefer direct APIs and validate process arguments when execution is required.
* Treat local files, IPC, and deserialized input as untrusted at relevant boundaries.
@@ -0,0 +1,6 @@
# Network and SSRF security
* Use HTTPS and never disable certificate or TLS validation.
* Restrict inbound and outbound access to required ports, interfaces, hosts, and protocols.
* Treat user-controlled URLs as dangerous: allowlist schemes and hosts, block localhost, metadata, and internal ranges, and revalidate redirects.
* Set timeouts, response-size limits, bounded retries, and cancellation for remote operations.
@@ -0,0 +1,6 @@
# Supply-chain security
* Keep dependencies minimal, maintained, and from verified sources; respect lockfiles and review identity and compatibility before adding or upgrading packages.
* Pin versions where appropriate and remove unused dependencies.
* Treat plugins, build scripts, CI actions, and generated artifacts as part of the attack surface.
* Use least privilege for build and deployment identities and never expose credentials in pipelines, logs, or artifacts.
+7
View File
@@ -0,0 +1,7 @@
# Web and frontend security
* Escape or sanitize untrusted content; never inject untrusted HTML or bypass framework sanitization.
* Protect state-changing browser requests from CSRF where applicable.
* Use `HttpOnly`, `Secure`, and appropriate `SameSite` cookie settings for sensitive sessions.
* Validate redirect targets, avoid sensitive data in URLs, and use CSP and clickjacking protections where applicable.
* Treat frontend code and browser storage as visible and never rely on client-side checks for authorization.