Critical Severity Patterns (K1-K14)

Critical Severity Patterns (K1-K14) represent a high-priority subset of identified bug patterns within the repository. These patterns focus specifically on high-impact areas such as security, data privacy (PII), data loss prevention, and financial impact. Unlike stack-specific patterns, these critical rules are often universal and must be checked against PRs touching authentication, public-facing endpoints, or user input processing.

The primary goal of documenting these patterns is to prevent recurring mistakes that lead to production failures or security vulnerabilities. These patterns are integrated into the development workflow through CLAUDE.md triggers and automated code review tools like Bugbot, ensuring that developers are alerted to potential risks before code is merged.

Sources: README.md:12-14, README.md:82-87, claude-md-snippets/critical.md:1-2

Authentication and Authorization (K1-K5)

Security patterns K1 through K5 address vulnerabilities in how users are identified and managed within the system.

Account Takeover and Privilege Escalation

A significant risk exists when linking accounts or resetting passwords. Systems must reject registration or password updates for existing OAuth accounts unless the user is specifically authenticated as the owner or verified via a one-time secure link. Furthermore, administrative privileges should never be granted based on unverified information like request body emails; verification via email or secure invite tokens is mandatory.

Sources: claude-md-snippets/critical.md:4-14

Network Exposure and Spoofing

Services bound to 0.0.0.0 expose administrative panels to the public network unless protected by pre-route authentication or firewalls. Additionally, rate limiters must not rely on the X-Forwarded-For (XFF) header directly due to spoofing risks; instead, trusted proxy middleware must be used to retrieve the true client host.

Sources: claude-md-snippets/critical.md:8-10, claude-md-snippets/critical.md:20-22

The diagram shows the secure flow for identifying client hosts behind proxies to prevent rate-limit spoofing.
Sources: claude-md-snippets/critical.md:8-10

Data Privacy and Secret Leakage (K6-K7, K13-K14)

These patterns focus on preventing the accidental exposure of sensitive information through logs, error responses, or network telemetry.

PII and Secret Exposure

Sensitive information such as emails, phone numbers, tokens, and API keys must be excluded from both application logs and API exception details. Error messages provided to users should be generic, while technical details are reserved for internal logging.

Sources: claude-md-snippets/critical.md:24-34, bugbot-rules/pii-in-logs.md:1-10

Telemetry and Query String Leaks (K14)

A critical vulnerability (K14) occurs when secrets are passed in URL query parameters. Monitoring SDKs (like Sentry) often automatically capture query strings in successful requests even if no explicit log line exists. This results in credentials being leaked to external telemetry platforms.

Sources: INTEGRATION.md:24-26, claude-md-snippets/critical.md:65-75

The sequence diagram illustrates how secrets in query parameters are captured by automated monitoring tools.
Sources: claude-md-snippets/critical.md:65-70

Multi-Tenant Isolation (K12)

Multi-tenant applications face the risk of data leakage between customers if scoping is not strictly enforced.

Scoping Logic

For any table containing a tenant_id, all SELECT, UPDATE, and DELETE operations must include a predicate filtering by the authenticated tenant. For INSERT operations, the tenant_id must be derived from the authenticated context, not from user-provided input.

Sources: claude-md-snippets/critical.md:55-63, bugbot-rules/tenant-row-scoping.md

Fail-Closed Implementation

The tenant context must implement a "fail-closed" mechanism where a missing context results in a hard error rather than a silent default. This ensures that a developer error in omitting the tenant scope does not lead to cross-tenant data access.

Sources: claude-md-snippets/critical.md:60-62, INTEGRATION.md:120-125

Database Integrity and Correction (K8-K11)

These patterns address data loss, corruption, and logical errors in database interactions.

Safe Wildcards and Credential Persistence

When using LIKE queries with user input, wildcards (_ and %) must be escaped to prevent unintended row matching. In workflows involving OTPs or link generation, the credential must be persisted in storage (DB/Redis) before the external transmission (SMS/Email). If storage fails, the system must "fail closed" and abort the transmission.

Sources: claude-md-snippets/critical.md:36-46

Return Value Validation (K11)

Pattern K11 addresses the common error of assuming success if no exception is thrown. Many functions return None, False, or 0 on failure. Code must explicitly check these return values before reporting success to the user or proceeding with irreversible actions.

# K11 Violation Example
saved = True  # Blindly assuming success
db.save(record)
return {"status": "ok"} # False positive for the user

# Correct Implementation
result = db.save(record)
if not result:
    raise InternalError("Save failed")
return {"status": "ok"}

Sources: claude-md-snippets/critical.md:49-54, INTEGRATION.md:107-112

Client-Side Security Policies (B-Series)

While implemented in the browser, these policies have critical security implications for the server-side application.

Content Security Policy (CSP) Issues

Broad CSP directives like 'none' can silently break features (e.g., OAuth forms). Furthermore, building CSP directives from unsanitized external strings can lead to injection attacks if the input doesn't strictly match the host-source grammar.

Sources: BY-STACK/browser-policy.md:21-35, BY-STACK/browser-policy.md:105-115

This diagram highlights that CSP failures prevent the request from ever reaching the server, leading to "silent" bugs from the server's perspective.
Sources: BY-STACK/browser-policy.md:7-12

These critical patterns form the baseline for safety across all projects. Developers must prioritize these rules during code implementation and review to maintain system integrity and security.

Sources: INTEGRATION.md:144-150