57f7c5667f
- Implemented `isValidEmail` utility with strict regex validation (rejects `<` and `>`) to prevent XSS vectors. - Updated `Contact.tsx` to use `isValidEmail` instead of weak regex. - Added comprehensive tests for `isValidEmail` in `src/utils/security.test.ts`. - Fixed flaky test in `src/pages/__tests__/Contact.test.tsx` by clearing `localStorage` in `afterEach`. - Added test case for invalid email submission. - Documented findings in `.jules/sentinel.md`. Co-authored-by: ragusa-it <196988693+ragusa-it@users.noreply.github.com>
2.5 KiB
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.