CARULY / TECHNICAL REPORT
Caruly — Security Review
Current controls, limitations, and priorities based on a source review.
1. Scope
Back to contents ↑This is a source-based engineering review of the Caruly prototype, not a penetration-test certificate. It covers server.js, storage.js, inspection.js, the UI, and the new Tech library. Production infrastructure, dependencies, and external services were not independently audited here. Do not place credentials or detailed operational secrets in this public library.
2. Current Controls
Back to contents ↑Random bearer draft tokens are stored as hashes. Cookies use HttpOnly and SameSite=Strict; HTTPS uses Secure. Photo reads and deletes are scoped to the draft owner. Database statements use bound values. Upload slots and image signatures are checked; images are limited to 10 MiB. The server bounds JSON bodies, keeps database/files outside static routes, sets nosniff, and checks write origins. Completion APIs enforce damage photos and inspection requirements. Tech files require explicit manifest membership and are contained inside their document root. HTML previews receive restrictive sandbox/CSP controls.
3. High-Priority Gaps
Back to contents ↑Demo code verification is not authentication or phone ownership. There is no real account recovery, logout/revocation workflow, or cross-device identity system. A stolen draft cookie provides access to that draft. Browser cookie expiry is not equivalent to a server-side session-expiration policy. Production account work must replace the demonstration mechanism before treating this as verified identity.
Initial draft fields have only basic server validation. Client-side requirements must not be relied on for business integrity. Upload signature tests are not comprehensive image sanitization or malware scanning. Consider decode/re-encode, metadata handling and abuse controls before accepting unrestricted production uploads.
4. Operations
Back to contents ↑Backups on the same disk do not protect against disk/account loss. Add off-site encrypted backups and practice restores. Disk quota prevents unlimited photo growth but database and request-abuse controls still need operational attention. Current rate limiting is in-process and based on the socket address; proxy behavior needs review before relying on per-user limits.
5. Content And Privacy
Back to contents ↑Tech is a public curated library when deployed. Never add seller contact information, images, identity documents, environment values, bearer tokens or private infrastructure credentials. HTML content is sandboxed and cannot run library scripts. This does not make arbitrary downloaded office files safe to open; only publish documents the maintainer has reviewed.
6. Evidence And Follow-Up
Back to contents ↑Automated tests exercise owner isolation, persistence, image handling and conditional validation. Browser flows were checked locally. No destructive testing or intrusive production security testing was performed. Prioritize identity, server-side business validation, off-site recovery and observability next.
7. Priorities And Acceptance Checks
Back to contents ↑High: replace fixed-code verification with real identity and session lifecycle. Accept when incorrect/expired codes fail, reuse is rejected, sessions can be revoked, and one seller cannot read another seller's records. Current cookie isolation tests do not prove telephone ownership.
High: establish independent recoverability. Accept when a tested restore of a database plus corresponding image files succeeds in an isolated environment and recovery time is documented.
Medium: strengthen business validation and file processing. Accept when bypassing browser validation cannot submit invalid details or unsupported image content, and upload limits cover abuse scenarios.
Medium: improve script policy and maintenance boundaries. The main UI contains inline code and has no application-wide strict CSP. The separate Tech surface has a restrictive policy. Test all workflows before enforcing a new main-site policy.
Medium: review rate limiting, logging and storage growth. Redact cookies/contact details from operational logs; verify limiter behavior behind Render's proxy. No live proxy configuration or account MFA audit was performed here.
8. Evidence Classification
Back to contents ↑Confirmed from source: fixed demo code, HttpOnly cookie, owner-scoped photo lookup, bound SQL, origin checks, body limits, same-disk backups and source-contained Tech files.
Verified locally: automated storage/inspection/session tests and targeted browser flows; fresh schema inventory.
Not verified: production account permissions, GitHub/Render MFA, disk encryption, historical secret exposure, off-site recovery, penetration testing and every alternate hostname.
No claim from the reference project's PostgreSQL or credential review has been imported as a finding about Caruly. No credentials were rotated or infrastructure security settings changed by this documentation task.
9. Sources And Maintenance
Back to contents ↑Prepared from the Caruly source tree and recorded development work on September 13, 2026. Reference report structure supplied by the owner. Update this snapshot when routes, schema, security, or deployment behavior changes. Do not copy unrelated project findings into this report.