{urlError}
` **Assessment: ✅ NOT EXPLOITABLE** `urlError` is set exclusively by the component itself: ```tsx setUrlError(t('uptime.invalidTcpFormat')); // from i18n translation setUrlError(''); // clear ``` The value always originates from the i18n translation system, never from raw user input. React JSX rendering (`{urlError}`) performs automatic HTML entity escaping on all string values. Even if a translation file were compromised to contain HTML tags, React would render them as escaped text. No XSS vector exists. --- ### Finding 2: `url.includes('://')` Bypass Risk **Assessment: ⚠️ LOW — UX guard only; backend must be authoritative** The scheme check `url.trim().includes('://')` correctly intercepts the primary misuse pattern (`tcp://`, `http://`, `ftp://`, etc.). Edge cases: - **Percent-encoded bypass**: `tcp%3A//host:8080` does not contain the literal `://` and would pass the frontend guard, reaching the backend with the raw percent-encoded value. - **`data:` URIs**: Use `:` not `://` — would pass the frontend check but would fail at the backend as an invalid TCP target. - **Internal whitespace**: `tcp ://host` is not caught (`.trim()` strips only leading/trailing whitespace). All bypass paths result in an invalid monitor that fails to connect. There is no SSRF risk, credential leak, or XSS vector from these edge cases. The backend API is the authoritative validator. **Recommendation:** No frontend change required. Confirm the backend validates TCP monitor URLs server-side (host:port format) independent of client input. --- ### Finding 3: `handleSubmit` Guard — Path Analysis **Assessment: ✅ DEFENSE-IN-DEPTH OPERATING AS DESIGNED** Three independent submission guards are present: 1. **HTML `required` attribute** on `name` and `url` inputs — browser-enforced 2. **Button `disabled` state**: `disabled={mutation.isPending || !name.trim() || !url.trim()}` 3. **JS guard in `handleSubmit`**: early return on empty fields, followed by TCP scheme check All three must be bypassed for an invalid TCP URL to reach the API through normal UI interaction. Direct API calls bypass all three layers by design; backend validation covers that path. The guard fires correctly in all 10 test-covered scenarios. --- ### Finding 4: `` with TCP Addresses (Informational) **Assessment: ℹ️ INFORMATIONAL — No security risk** TCP monitor URLs (e.g., `192.168.1.1:8080`) are rendered inside ``. A browser interprets this as a relative URL reference; clicking it fails gracefully. React sanitizes `javascript:` hrefs since v16.9.0. No security impact. --- ## Summary | Check | Result | Notes | |-------|--------|-------| | TypeScript | ✅ PASS | 0 errors | | ESLint | ✅ PASS | 0 errors, 839 pre-existing warnings | | Local Patch Report | ✅ PASS | Artifacts generated | | Unit Tests (TCP UX) | ✅ PASS | 10/10 | | Full Unit Suite | ✅ NO FAILURES OBSERVED | Coverage % deferred to CI | | Lefthook Pre-commit | ✅ PASS | All 6 active hooks passed | | Trivy | ⚠️ N/A | Not installed; Semgrep used as compensating control | | Semgrep | ✅ PASS | 0 findings | | XSS (`urlError`) | ✅ NOT EXPLOITABLE | i18n value + React JSX escaping | | Scheme check bypass | ⚠️ LOW | Frontend UX guard only; backend must validate | | `handleSubmit` guard | ✅ CORRECT | Defense-in-depth as designed | --- ## Overall: ✅ PASS PR-5 implements TCP monitor UX with correct validation layering, clean TypeScript, and complete unit test coverage of all TCP-specific behaviors. One low-severity observation (backend must own TCP URL format validation independently) does not block the PR — this is an existing project convention, not a regression introduced by these changes. --- # QA Audit Report — PR-1: Allow Empty Value in UpdateSetting **Date:** 2026-03-17 **Scope:** Remove `binding:"required"` from `Value` field in `UpdateSettingRequest` **File:** `backend/internal/api/handlers/settings_handler.go` --- # QA Security Audit Report — Rate Limit CI Fix **Audited by**: QA Security Auditor **Date**: 2026-03-17 **Spec reference**: `docs/plans/rate_limit_ci_fix_spec.md` **Files audited**: - `scripts/rate_limit_integration.sh` - `Dockerfile` (GeoIP section, non-CI path) - `.github/workflows/rate-limit-integration.yml` --- ## Pre-Commit Check Results | Check | Command | Result | |-------|---------|--------| | Bash syntax | `bash -n scripts/rate_limit_integration.sh` | ✅ PASS (exit 0) | | Pre-commit hooks | `lefthook run pre-commit` (project uses lefthook; no `.pre-commit-config.yaml`) | ✅ PASS — all 6 hooks passed: `check-yaml`, `actionlint`, `end-of-file-fixer`, `trailing-whitespace`, `dockerfile-check`, `shellcheck` | | Caddy admin API trailing slash (workflow) | `grep -n "2119" .github/workflows/rate-limit-integration.yml` | ✅ PASS — line 71 references `/config/` (trailing slash present) | | Caddy admin API trailing slash (script) | All 6 occurrences of `localhost:2119/config` in script | ✅ PASS — all use `/config/` | --- ## Security Focus Area Results ### 1. Credential Handling — `TMP_COOKIE` **`mktemp` usage**: `TMP_COOKIE=$(mktemp)` at line 208. Creates a file in `/tmp` with `600` permissions via the OS. ✅ SECURE. **Removal on exit**: The `cleanup()` function at line 103 removes the file with `rm -f "${TMP_COOKIE:-}"`. However, `cleanup` is only registered via explicit calls — there is **no `trap cleanup EXIT`**. Only `trap on_failure ERR` is registered (line 108). **Gap**: On 5 early `exit 1` paths after line 208 (login failure L220, auth failure L251, Caddy readiness failure L282, security config failure L299, and handler verification failure L316), `cleanup` is never called. The cookie file is left in `/tmp`. **Severity**: LOW — The cookie contains session credentials for a localhost test server (`ratelimit@example.local` / `password123`, non-production). CI runners are ephemeral and auto-cleaned. Local runs will leave a `/tmp/tmp.XXXXXX` file until next reboot or manual cleanup. **Note**: The exit at line 386 (inside the 429 enforcement failure block) intentionally skips cleanup to leave containers running for manual inspection. This is by design and acceptable. **Recommendation**: Add `trap cleanup EXIT` immediately after `trap on_failure ERR` (line 109) to ensure the cookie file is always removed. --- ### 2. `curl` — Sensitive Values in Command-Line Arguments Cookie file path is passed via `-c ${TMP_COOKIE}` and `-b ${TMP_COOKIE}` (unquoted). No credentials, tokens, or API keys are passed as command-line arguments. All authentication is via the cookie file (read/write by path), which is the correct pattern — cookie values never appear in `ps` output. **Finding (LOW)**: `${TMP_COOKIE}` is unquoted in all 6 curl invocations. `mktemp` on Linux produces paths of the form `/tmp/tmp.XXXXXX` which never contain spaces or shell metacharacters under default `$TMPDIR`. However, under a non-standard `$TMPDIR` (e.g., `/tmp/my dir/`) this would break. This is a portability issue, not a security issue. **Recommendation**: Quote `"${TMP_COOKIE}"` in all curl invocations. --- ### 3. Shell Injection All interpolated values in curl `-d` payloads are either: - Script-level constants (`RATE_LIMIT_REQUESTS=3`, `RATE_LIMIT_WINDOW_SEC=10`, `RATE_LIMIT_BURST=1`, `TEST_DOMAIN=ratelimit.local`, `BACKEND_CONTAINER=ratelimit-backend`) - Values derived from API responses stored in double-quoted variables (`"$CREATE_RESP"`, `"$SEC_CONFIG_RESP"`) No shell injection vector exists. All heredoc expansions (`cat <