ragusaitweb/.jules/sentinel.md

2025-02-12 - Missing Security Headers in Firebase Config

Vulnerability: The application is served without standard security headers (CSP, X-Frame-Options, etc.), leaving it vulnerable to XSS, Clickjacking, and MIME sniffing. Learning: Single Page Applications (SPAs) served via static hosting (like Firebase) rely on infrastructure configuration for security headers, which are often overlooked. Default configurations are rarely secure enough. Prevention: Always configure firebase.json (or equivalent) with strict security headers (CSP, X-Frame-Options, HSTS, etc.) at project setup.

2026-01-26 - Client-Side Rate Limiting for Serverless Forms

Vulnerability: Contact forms using client-side services (like EmailJS) without backend middleware are vulnerable to spam and quota exhaustion. Learning: While true rate limiting requires a backend, client-side throttling via localStorage provides a necessary friction layer for legitimate users and simple bots, protecting external service quotas. Prevention: Implement reusable rate-limit hooks for all public-facing form submissions in static/serverless applications.

2026-02-13 - State Leakage in Tests masking Security Failures

Vulnerability: Flaky tests caused by localStorage state leakage (e.g. rate limits persisting between tests) can prevent security features from being properly verified, leading to false negatives or untested paths. Learning: Global state like localStorage must be explicitly cleared in afterEach blocks in test environments (jsdom). Failing to do so can cause subsequent tests to fail or behave unpredictably, especially for rate-limiting logic. Prevention: Always include localStorage.clear() in afterEach (or beforeEach) when testing components that rely on local storage.

2026-02-13 - Strict Email Validation vs HTML5 Validation

Vulnerability: Standard email regexes and HTML5 validation are often too permissive, allowing XSS vectors (like <script>) in email fields if not properly sanitized/rejected. Learning: While HTML5 browsers block some invalid emails, relying solely on them is insufficient for defense-in-depth. Application-level validation should explicitly reject dangerous characters (<, >) to prevent stored XSS or injection if the data is processed by less-secure backends. Prevention: Implement strict, reusable validation functions (isValidEmail) that reject XSS vectors, and ensure tests verify this logic by bypassing browser validation if necessary.

2026-02-14 - Strict Email Regex vs RFC Compliance

Vulnerability: Standard email validation often allows characters like quotes (") or backticks (`) which can be vectors for XSS in HTML attribute contexts. Learning: While RFCs allow quoted local parts (e.g., "user"@example.com), these are rare in practice and pose significant security risks in web applications. It is often safer to explicitly reject them. However, apostrophes (') are common in names (O'Connor) and should be allowed, relying on sanitization (Defense in Depth) rather than validation to handle them safely. Prevention: Use a hybrid approach: Strict validation (reject quotes/backticks) for high-risk characters, coupled with output sanitization (sanitizeInput) for characters that must be allowed but are still risky (apostrophes).

2026-02-14 - Blocking Disposable Domains

Vulnerability: Allowing users to register or submit forms with disposable email addresses (e.g., mailinator.com) can lead to spam, abuse, and polluted data. Learning: While true email verification requires a backend or API, a simple client-side blocklist of common disposable domains is a highly effective, low-cost first line of defense. Prevention: Maintain a list of known disposable domains (e.g., BLOCKED_DOMAINS) and check the domain part of the email address during validation.

2026-02-14 - Backtick Injection in Template Strings

Vulnerability: Standard HTML sanitization often ignores backticks ( ), which can be dangerous if the sanitized string is injected into a JavaScript template literal context. Learning: While HTML entities (<, ") protect HTML contexts, modern JS uses backticks for strings. Failing to escape them allows attackers to break out of the string boundary if the data is used in a JS context. Prevention: Explicitly replace backticks with ` in sanitization routines intended for general-purpose use.