# Needs Validation — Vienotais Zemes Reģistrs Security Audit

**Target:** https://vienotaiszemesregistrs.tech/hakatons/#/
**Audit Date:** 2026-10-26
**Auditor:** Automated remote security audit
**Note:** All items below require additional testing that could not be completed in the available remote scope. Each item is marked with its priority, required environment, and specific test steps.

---

## N-001 — HSTS enforcement validation (F-003)
**Priority:** HIGH | **Required:** Active HTTPS server, HTTP redirect flow access

### What needs validating
That `Strict-Transport-Security` header or `enforce_https` directive is properly configured on the production Caddy server, and that it has a sufficient max-age value.

### Current state
The HSTS status was marked as **Candidate** because the audit only confirmed:
- HTTP→HTTPS redirect exists (308)
- No HSTS header present on current responses

### Test steps
1. Deploy test instance with `enforce_https` and `Strict-Transport-Security` in Caddy config
2. Send HTTP request to `http://<host>/hakatons/` — verify 308 redirect
3. Capture HTTPS response headers — confirm HSTS present with max-age ≥ 31536000
4. Verify preloads list submission for production domain

### Blocking factor
Cannot modify server-side configuration; requires access to Caddyfile on the hosting environment.

---

## N-002 — CSP effectiveness on SPA (F-010, F-012)
**Priority:** HIGH | **Required:** Deployed CSP header + browser devtools

### What needs validating
That any deployed CSP does not break the Vue 3 SPA's module loading chain, and that a nonce-based approach correctly handles dynamic script and style injection during runtime.

### Current state
CSP is currently only present on **error pages** (`default-src 'none'`) — this would block all application scripts if applied to the success page. The SPA will require full CSP configuration.

### Test steps
1. Deploy CSP headers for the SPA: `script-src`, `style-src` directives with nonce injection
2. Open browser devtools → Console — check for CSP violations
3. Verify module script integrity via subresource hashes or dynamic nonce propagation
4. Test inline event handlers, `<script type="module">`, and CSS injected via JS renderers
5. Validate Content-Security-Policy-Report-Only mode produces JSON reports for `/report-uri`

### Blocking factor
Requires CSP deployment (F-010) before this test can run; currently blocked because production has no functional CSP on the SPA page.

---

## N-003 — Authenticated CSRF testing (F-001)
**Priority:** CRITICAL | **Required:** Test account, CORS allowlist + valid API endpoints

### What needs validating
That when `access-control-allow-origin: *` is combined with real authenticated API endpoints, cross-site request forgery is possible from an attacker-controlled origin. Current CORS config permits all methods including PUT/DELETE/PATCH.

### Current state
The CORS wildcard was confirmed on the health endpoint (`/api/health`) which returns only public metadata. No authenticated endpoints are currently available for testing.

### Test steps
1. Obtain test credentials (login with any registered user)
2. Deploy attacker site with CSRF PoC forms for PUT/DELETE/PATCH requests to target API paths
3. Navigate via browser on victim's behalf — verify request completes without auth token error
4. Confirm state-changing operations execute and return 200 success responses

### Blocking factor
No authenticated user credentials available; backend API endpoints are currently returning 404 (non-existent). Requires active backend services + test user accounts.

---

## N-004 — Backend SSRF via proxy to government APIs (F-011)
**Priority:** HIGH | **Required:** Source code access, SSRF scanner, internal network probe targets

### What needs validating
That the Express server-side fetch proxy validates URLs against a domain/IP allowlist and blocks redirect chains targeting private networks or `localhost`.

### Current state
Static analysis of the SPA bundle confirmed 14+ government API URLs are referenced. The actual backend proxy implementation was not accessible — no source code or running backend on non-standard ports detected.

### Test steps
1. Acquire Express server source code (Git repo access)
2. Identify all `fetch()` calls to external domains within the `/hakatons/api/*` route handlers
3. For each target URL: run an SSRF scan against internal network ranges (RFC 1918, RFC 6598, localhost)
4. Test redirect chain handling — deploy local HTTP server that returns 302 to `http://localhost:27017` and confirm proxy rejects or fails securely

### Blocking factor
No backend port open for SSH/HTTP access beyond the standard 443 reverse-proxied URL. Source code not included in static asset bundle.

---

## N-005 — DNS security configuration (F-004)
**Priority:** MEDIUM | **Required:** Domain registrar access, DNS management at Name.com

### What needs validating
That enabling DNSSEC, CAA, SPF, DKIM, and DMARC in the current registrar does not break existing email routing or require additional MX record configuration.

### Current state
DNS configuration was fully audited via public dig queries: no DNSSEC, no TXT records (SPF/DKIM/DMARC), no MX records, no AAAA records confirmed.

### Test steps
1. Register at Name.com DNS management panel for `vienotaiszemesregistrs.tech`
2. Enable DNSSEC → verify chain-of-trust propagates to public resolvers within 48h
3. Add CAA record: `CAA 0 issue "letsencrypt.org"` or appropriate CA(s)
4. Add SPF, DKIM, DMARC TXT records appropriate for a no-email domain
5. Verify with MX Toolbox and dnssec-analyzer.com

### Blocking factor
Requires Name.com account access — cannot be tested without registrar credentials.

---

## N-006 — Email delivery security (infrastructure-level)
**Priority:** LOW | **Required:** Active SMTP infrastructure or MX record validation

### What needs validating
That when email infrastructure is deployed, DKIM signing and DMARC policy enforcement are active to prevent spoofing from the government-related addresses (`info@vienotaiszemesregistrs.tech`, etc.).

### Current state
No active mail routing found — `mx` query returned no records. SPF/DKIM/DMARC all absent.

### Test steps
1. Once MX records are deployed: send email to `test-mx-check@mxtoolbox.com` or similar
2. Verify DKIM signature validates via public DNS key lookup
3. Send DMARC test email from the domain and validate report inbox (p=reject should quarantine all spoofed mail)

### Blocking factor
No email infrastructure is currently deployed; cannot test until MX records exist.

---

## N-007 — IPv6 connectivity test (F-004)
**Priority:** LOW | **Required:** Active AAAA DNS record

### What needs validating
That once an AAAA record is added and the server binds to an IPv6 address, TLS certificates are correctly served for both IPv4 and IPv6.

### Current state
No AAAA record found via public dig query. Only A record (`158.247.224.82`) confirmed.

### Test steps
1. Add AAAA record via Name.com → `dig vnzr ipv6.google.com` to verify propagation
2. Access `https://[ipv6-address]/hakatons/` — confirm 200 response with same TLS cert (Let's Encrypt wildcard)
3. Verify no dual-stack misconfiguration breaks Caddy TLS automation

### Blocking factor
AAA record must be added by domain owner before testing.

---

## N-008 — Security.txt policy validation (F-009)
**Priority:** LOW | **Required:** Write access to `.well-known/` path on the server

### What needs validating
That `/.well-known/security.txt` is served with proper Content-Type (`text/plain`) and resolves before any SPA routing intercepts the request.

### Current state
`.well-known/security.txt` not deployed — returns 404. This is a policy recommendation, not a technical vulnerability.

### Test steps
1. Deploy security.txt at `https://vienotaiszemesregistrs.tech/.well-known/security.txt`
2. Verify response Content-Type is `text/plain` without charset errors
3. Confirm Caddy config serves `.well-known/` static files before SPA catch-all rewrite

### Blocking factor
Requires write access to server file system or Caddyfile configuration for static path handling.

---

## N-009 — Server-side cache control (Cache-Control validation)
**Priority:** MEDIUM | **Required:** Response cache inspection

### What needs validating
That the `Cache-Control: public, max-age=0` setting on SPA responses is intentionally used to force origin fetches while still allowing forward/proxy caching. Confirm this does not serve stale or unvalidated copies of application bundles from CDN edge caches.

### Current state
`Cache-Control: public, max-age=0` confirmed on `/hakatons/` (SPA root) via header inspection. No `ETag` or `Last-Modified` cache validation headers analyzed for consistency with this directive.

### Test steps
1. Request SPA root multiple times in quick succession — confirm each fetch hits origin (not stale HTTP cache)
2. Check `x-Cache` header from Caddy/CDN proxy for HIT/MISS status
3. Verify ETag freshness check returns 304 Not Modified after initial fetch

### Blocking factor
Requires repeated requests to the production server and comparison of ETag values — currently a Candidate due to insufficient data points on cache behavior over time.

---

## N-010 — Authenticated XSS vulnerability (application-level)
**Priority:** HIGH | **Required:** Test account with form input capability

### What needs validating
That any user input fields in the live application safely escape output, prevent client-side DOM-based injection through query parameters or localStorage, and do not expose `document.write` or `innerHTML` to user-supplied data.

### Current state
Static analysis of SPA JS bundle found no explicit `document.write()` or user-controlled `innerHTML` patterns, but could not confirm runtime behavior of Vue component rendering (Vue typically sanitizes by default). No authenticated application access available for interactive XSS testing.

### Test steps
1. Login with test account → identify all data-entry forms (search fields, profile input, etc.)
2. Insert reflected/payload strings into each field: `'"><script>alert(1)</script><'`
3. Submit and inspect rendered HTML via devtools — verify no script blocks execute in browser context
4. Test localStorage/sessionStorage injection → confirm Vue templates do not bind directly to unsanitized values

### Blocking factor
No user credentials available. No running backend endpoints to accept form submissions or return dynamic content.

---

## Summary of Priorities

| Priority | Count | Items |
|----------|-------|-------|
| Critical | 1 | N-003 (CSRF with auth) |
| High | 4 | N-001, N-002, N-004, N-010 |
| Medium | 3 | N-005, N-009, plus existing MEDIUM confirmations |
| Low | 3 | N-006, N-007, N-008 |

**Next steps for validation:**
1. Obtain test user credentials for the application
2. Acquire Name.com domain management access
3. Request Express server source code from development team
4. Coordinate CSP deployment for pre-launch testing with Content-Security-Policy-Report-Only mode