Security Review – August 2026 (Consolidated)

• Review Date: 1 August 2026
• Reviewer: CTO (with AI-assisted static review)
• Scope: Full static security review of the CheckTick platform covering authentication and redirect flows, email rendering, settings hardening, DRF defaults, HashiCorp Vault integration, LLM (AI survey generator + translation), the public REST API, OIDC SSO, user-uploaded icons and survey images, user/organisation management, billing webhooks, and styling/theme CSS.
• Method: Static source review of checktick_app/core/views.py, checktick_app/core/email_utils.py, checktick_app/core/oidc_views.py, checktick_app/core/views_billing.py, checktick_app/core/theme_utils.py, checktick_app/core/models.py, checktick_app/surveys/views.py, checktick_app/surveys/vault_client.py, checktick_app/surveys/llm_client.py, checktick_app/surveys/models.py, checktick_app/api/authentication.py, checktick_app/api/views.py, checktick_app/settings.py, and the relevant templates. Cross-referenced against the documented security model in docs/vault.md, docs/llm-security.md, docs/api.md, and docs/security-overview.md.
• Status: ✅ Remediation complete — F1, F2, F5, F6, F7, F8, F9, F10, F11, F12, F13, F14, F15, F16, F17, and F18 resolved; all 18 findings closed

Summary

This consolidated review identifies 18 findings (F1–F18): 2 High, 6 Medium, 9 Low, 1 Info. No finding is assessed Critical, and none involve direct exfiltration of patient data at rest or compromise of at-rest encryption. The two High findings are both stored, authenticated-user-reachable vulnerabilities: a web recovery console that bypasses the documented Shamir custodian-share control (F6), and an SVG upload that enables stored XSS via direct /media/ access (F12). F18 was identified during the follow-up audit of the dataset web views performed as part of the F8 remediation. All 18 findings have been remediated with regression tests.

All findings resolved. F3, F4, and F11 were resolved on 2 August 2026. F1, F2, F6, and F12 were resolved on 1 August 2026; F5, F7, F8, F9, F10, F13, F14, F15, F16, F17, and F18 were resolved on 2 August 2026.

High findings

F6 — Web recovery console bypasses Shamir custodian-share control (High)

Location: - checktick_app/surveys/views.py → recovery_execute (L10523–10573) - checktick_app/surveys/models.py → RecoveryRequest.execute_recovery (L4721–4773) - checktick_app/settings.py L953–955 (documented removal of PLATFORM_CUSTODIAN_COMPONENT) - checktick_app/surveys/management/commands/execute_platform_recovery.py (the intended, secure path)

Description

The documented ethical-recovery model (docs/vault.md §"Platform Key Rotation", docs/compliance/recovery-dashboard.md, and the management command docstring) requires 3 of 4 Shamir custodian shares to reconstruct the platform custodian component before a survey KEK can be recovered from Vault. The execute_platform_recovery management command implements this correctly: it calls reconstruct_secret([share1, share2, share3]) and passes the result into vault.recover_user_survey_kek(..., platform_custodian_component=custodian_component).

However, there is a second, web-based execution path that does not enforce the custodian-share requirement:

1. surveys/views.py::recovery_execute (L10527) is a @login_required @superuser_required @require_http_methods(["POST"]) view that accepts a new_password from a form POST.
2. At L10573 it calls recovery_request.execute_recovery(admin=request.user, new_password=new_password).
3. RecoveryRequest.execute_recovery (models.py L4737) reads the custodian component directly from settings: python custodian_component = bytes.fromhex(settings.PLATFORM_CUSTODIAN_COMPONENT)
4. settings.py L953 explicitly states this setting was removed: # Note: PLATFORM_CUSTODIAN_COMPONENT removed for security # Platform recovery now requires 3 custodian shares via management command

This means the web path is in one of two states, both of which are problems:

• If the env var is unset (the documented state): settings.PLATFORM_CUSTODIAN_COMPONENT raises AttributeError at L4737, so the web recovery console crashes with a 500 the first time a superuser tries to execute an approved recovery. The dual-admin approval + time-delay workflow runs to completion and then fails at the final step — a denial-of-service on the recovery workflow and a poor experience for a clinician who has already been identity-verified and is waiting for data restoration.
• If an operator re-adds the env var to make the web path work (a likely response to the above): a single superuser can execute recovery of any user's survey KEK without presenting any custodian shares. This silently reverts the split-knowledge control that the Shamir scheme was introduced to provide. The audit trail records the superuser action but not any custodian participation, because none occurred.

Impact

The documented threat model for ethical recovery is that no single administrator — not even a superuser — can decrypt a user's survey data without custodian participation. The web path violates that invariant. In the crash case it is an availability bug; in the silently-fixed case it is a single-party decryption primitive that defeats the entire custodian control. For a healthcare platform processing patient-reported data, this is one of the two most serious findings in this review.

Severity rationale: High. The control being bypassed is a primary defence against insider abuse and is documented as a DSPT-relevant split-knowledge control. Exploitability depends on whether the env var is set, but the misconfiguration is plausible and the impact on the threat model is structural.

Recommended fix

Pick one of the following, in order of preference:

1. Remove the web execution path entirely. Delete recovery_execute (or make it redirect to documentation instructing the operator to use python manage.py execute_platform_recovery). The management command is the intended secure path; the web console should only take requests through dual approval + time delay, then hand off to the CLI for execution. Update RecoveryRequestAdmin.execute_recovery (admin.py L1116) to point at the same documentation.
2. Make the web path require custodian shares too. Add a form collecting 3 shares, reconstruct via shamir.reconstruct_secret, and pass the result into vault.recover_user_survey_kek. This is more engineering effort and expands the attack surface (shares entered into a browser), so option 1 is preferred.
3. At minimum, make the failure loud. If settings.PLATFORM_CUSTODIAN_COMPONENT is unset, execute_recovery should raise a clear ImproperlyConfigured at startup or a 503 at request time with a message directing the operator to the management command — never a generic 500, and never a silent fallback.

Either way, RecoveryRequest.execute_recovery (the model method) should be deleted or refactored so it cannot read the custodian component from settings. The setting itself should be removed from the codebase entirely (not just commented out) so that any deploy that sets it fails loudly.

Regression risk: Medium. The web recovery console is a superuser-only workflow; removing it changes operator behaviour. Coordinate with the platform-admin runbook (docs/compliance/recovery-dashboard.md) before merging. The management command path is unaffected.

Resolution (1 August 2026): The web execution endpoint was removed, admin operators are directed to execute_platform_recovery, the model method requires a caller-supplied custodian component, and startup rejects PLATFORM_CUSTODIAN_COMPONENT in the environment. Recovery therefore requires 3 of 4 custodian shares on a secure terminal.

F12 — SVG upload → stored XSS via direct /media/ access (High)

Location: - checktick_app/surveys/views.py L7612–7650 (ALLOWED_IMAGE_EXTENSIONS, _validate_and_process_image) - checktick_app/surveys/views.py L7719–7768 (_handle_image_upload) - checktick_app/surveys/models.py L2331+ (QuestionImage.image = ImageField(upload_to=question_image_upload_path)) - checktick_app/settings.py L455–457 (MEDIA_URL = "/media/", MEDIA_ROOT = BASE_DIR / "media") - checktick_app/surveys/templates/surveys/detail.html L523 (<img src="{{ img.image.url }}">)

Description

The survey builder's image-choice question type allows survey creators to upload images that are then shown to respondents. The upload validator _validate_and_process_image explicitly permits SVG:

ALLOWED_IMAGE_EXTENSIONS = {".png", ".jpg", ".jpeg", ".webp", ".svg"}
ALLOWED_IMAGE_MIMES = {"image/png", "image/jpeg", "image/webp", "image/svg+xml"}
...
# For SVG files, we skip dimension checks and PIL processing
if ext == ".svg" or content_type == "image/svg+xml":
    return True, ""

SVG files are stored unmodified to MEDIA_ROOT and served from MEDIA_URL (/media/). The image is rendered to respondents via:

<img src="{{ img.image.url }}" alt="{{ img.label|default:'Image option' }}" ... />

There are two XSS-relevant facts about how browsers handle SVG:

1. <img src="...svg"> does NOT execute scripts. When an SVG is loaded via an <img> tag, the browser renders it in "image mode" — scripts, external resources, and interactive elements are disabled. So the detail.html render path is not directly an XSS sink.

2. Direct navigation to the SVG URL DOES execute scripts. If a user visits https://checktick.example/media/surveys/.../evil.svg directly — or if the SVG URL is embedded anywhere that fetches it as a top-level document or via <embed>, <object>, <iframe>, or fetch() — the browser serves it with Content-Type: image/svg+xml and executes any <script> tags inside it. The script runs in the origin of the CheckTick site (because /media/ is same-origin), giving it full access to the victim's session cookies (HttpOnly session cookie is not accessible to JS, but CSRF cookie and any in-page data are) and the ability to make authenticated requests.

The SECURE_CONTENT_TYPE_NOSNIFF = True setting does not help here because image/svg+xml is a legitimate content type — the browser correctly renders it as SVG, and SVG-with-script is valid SVG.

Attack scenario

1. A survey creator (any authenticated user with survey-edit permission — Pro tier and above) creates an image-choice question and uploads an SVG containing: ```xml

`` 2. The validator passes it (extension.svg, MIMEimage/svg+xml, size < 1MB). 3. The file is stored at/media//evil.svg. 4. The creator shares the direct URL with a victim (e.g. via email, or by embedding it in a page that uses