7ef5c5f779
- Added a hidden `website` input field to the contact form as a honeypot. - Implemented silent rejection logic: if the honeypot is filled, the form simulates success but does not send the email. - Added a `.honeypot` CSS class to visually hide the field while keeping it accessible to bots. - Updated `src/pages/Contact.tsx` to handle the new field and logic. - Updated `src/pages/__tests__/Contact.test.tsx` to verify the honeypot logic and fixed existing tests that were failing due to blocked domain usage (`example.com`). - Recorded security learnings in `.jules/sentinel.md`. Co-authored-by: ragusa-it <196988693+ragusa-it@users.noreply.github.com>
35 lines
4.4 KiB
Markdown
35 lines
4.4 KiB
Markdown
## 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 - Blocked Domains in Test Data
|
|
**Vulnerability:** Tests failing unexpectedly on valid inputs can lead to disabling security features or ignoring real bugs.
|
|
**Learning:** The application blocks specific domains (like `example.com`) in its validation logic. Using these domains in test data (e.g. `john@example.com`) causes tests to fail with "Invalid email", confusing debugging efforts.
|
|
**Prevention:** Always use safe, non-blocked domains (e.g. `valid-email.com` or a custom test domain) in test fixtures, and check the security configuration (`BLOCKED_DOMAINS`) when validation tests fail unexpectedly.
|