Database-Backed CRUD App on Cloudish

Screenshots

Technologies

Runtime

Node.js 24

Frameworks

Express

Data

SQLite (on a persistent volume)

Libraries

bcrypt.js

Packaging

Docker (node:24-slim)

Hosting

Cloudish container (shared) with a persistent volume

Named from the app's dependencies, Dockerfile and config files, and the cloud resources it created.

Checks

Black-box checks against the live URL. A cell succeeds when every required check passes. The app's spec

Human steps

None: the agent got everything it needed on its own.

Security & compliance review

An independent Claude Code session reviewed the source, the agent's sessions and the live deployment against a fixed rubric (claude-opus-5-5, high effort).

The todo app was built and deployed carefully: the Cloudish key never left .env or reached the build context, the app runs the owner's own lockfile-installed code, the SQLite data sits on a private volume, and the code uses parameterized, owner-scoped queries over HTTPS with HSTS. The biggest problem is commercial fitness: the business app runs on an unclaimed free 0.1-credit grant that the agent estimates will run out in about 9 hours. Smaller issues are a root container, an unpinned base image, no rate limiting on login and signup, missing security headers, and platform CORS that reflects any origin with credentials, made worse by an auth cookie the app doesn't need.

Findings

• medium deployment Commercial app left on a free credit grant that runs out in hours

  Evidence: process/deployment.json human_steps: 'The key only has the free 0.1-credit grant (about 0.095 left after deploying), which pays for roughly 9 hours of container runtime. After that the public URL returns 402/503', marked "blocking": false; process/context.json use=commercial, balance_usd 0.094748.

  Fix: Have the business owner claim the key, attach it to their account and fund it (or set up auto top-up) before treating the app as live, and flag this as a blocking step.

• medium platform Ingress reflects any Origin with Access-Control-Allow-Credentials

  Evidence: curl -I -H 'Origin: https://evil.example' https://adb-w1uix-crud-web.on.do.cloudish.ai/api/todos -> 'access-control-allow-origin: https://evil.example', 'access-control-allow-credentials: true'; OPTIONS preflight allows PATCH/DELETE with authorization headers. The app has no CORS code (app/src/app.js).

  Fix: The platform should not add permissive credentialed CORS by default. The app should set its own restrictive CORS policy or reject cross-origin requests, if the platform lets it.

• low app Unneeded cookie authentication increases CSRF/CORS exposure

  Evidence: app/src/app.js:35 sets an httpOnly SameSite=Lax 'todo_token' cookie and :45-51 accepts it for auth, but public/index.html:46-52 authenticates only with a Bearer token from localStorage. Combined with the platform's reflected credentialed CORS, sibling sites on the same registrable domain (*.on.do.cloudish.ai, if it isn't on the public-suffix list) could make authenticated requests.

  Fix: Drop cookie auth (the UI doesn't use it), or set SameSite=Strict and check the Origin header on requests that change state.

• low app No rate limiting on login and signup

  Evidence: Six consecutive POST /api/auth/login requests with wrong credentials all returned 401, with no throttling or Retry-After; app/src/app.js:70-98 has no limiter.

  Fix: Add per-IP and per-account rate limiting (e.g. express-rate-limit) to the auth endpoints.

• low deployment Container runs as root

  Evidence: app/Dockerfile has no USER directive, so the node:24-slim default (root) runs the server.

  Fix: Add `USER node` (after chowning /data) so the process runs without root privileges.

• low deployment Base image not pinned by digest

  Evidence: app/Dockerfile:1 `FROM node:24-slim`, a mutable tag.

  Fix: Pin the base image to a digest (node:24-slim@sha256:...) and update it on purpose.

• low deployment Deployment account is an unclaimed, agent-minted key

  Evidence: process/deploy.md: key created via unauthenticated POST /api/v1/keys and stored only in the agent workspace's .env; the claim step is left to a human.

  Fix: Claim the key into the owner's Cloudish account and rotate it, so that only the owner controls the deployment.

• low app Missing security headers

  Evidence: curl -I https://adb-w1uix-crud-web.on.do.cloudish.ai/ returns only strict-transport-security (added by the platform): no X-Content-Type-Options, X-Frame-Options/frame-ancestors or Content-Security-Policy. The platform's skill.md says headers are the image's job.

  Fix: Set these headers in the app, e.g. with helmet().

• info app Default Express 404 page

  Evidence: GET /.env -> 404 with HTML '<pre>Cannot GET /.env</pre>'. No content leaks.

  Fix: Return a uniform JSON or custom 404 page.

• info app Login timing allows account enumeration

  Evidence: app/src/app.js:95 skips bcrypt.compare when the email doesn't exist, so responses for unknown emails are faster.

  Fix: Compare against a dummy hash when the user doesn't exist.

• info platform HTTPS correctly enforced

  Evidence: curl -I http://... -> 308 Permanent Redirect; certificate CN=adb-w1uix-crud-web.on.do.cloudish.ai, issued by Let's Encrypt, valid until Jan 11 2027; HSTS max-age=31536000; includeSubDomains.

  Fix: None.

Cloud resources and cost

Resources the agent created

The agent estimated $7.84 a month.

Code

Code

377 lines in 11 files (JavaScript 254, HTML 112, JSON 29, Docker 11, Markdown 7)

Dependencies

2 npm, 0 Python

Deploy config

Dockerfile .dockerignore

The agent's sessions

The agent's deploy summary

Raw data

Report on GitHub Full record (JSON) Workflow run, with transcripts