Data / Visualization App on Render

Screenshots

Technologies

Runtime

Node.js 24

Frameworks

Express

Libraries

Chart.js

Packaging

Render Blueprint (render.yaml)

Hosting

Render web service (free, running the prebuilt image node:24-alpine)

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

• Sign up for an account and verify the email address · 3 min
  prerequisite: account setup
• Create an API token and hand it to the agent · 2 min
  prerequisite: account setup

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 Render dashboard is live over HTTPS, exposes no files or secrets, and the app code is clean (validated dates, textContent rendering, clamped pagination). The main weaknesses are in how it was deployed and hosted. The code is an opaque base64 tarball uploaded as a Render secret file and run on a floating node:24-alpine tag; the container runs as root and reinstalls packages from npm on every start. It is also a commercial app on Render's free plan, which sleeps when idle, and the app sets no security headers.

Findings

• medium deployment App code delivered as an uploaded secret-file tarball, not built from an owner-controlled source

  Evidence: process/deploy.md:65 `tar czf /tmp/app.tgz app.js server.js ...`; deploy.md:78 creates the service with `"secretFiles":[{"name":"app.tgz.b64","content":b}]` and imagePath docker.io/library/node:24-alpine; start.sh runs `base64 -d /etc/secrets/app.tgz.b64 | tar xz`. The repo was never pushed (git status shows untracked files). app/render.yaml (runtime: node, npm ci/npm start) does not match the live service.

  Fix: Push the code to a Git repository the owner controls and deploy it through a Render Blueprint or native Node runtime (or a Dockerfile built from that repo), so production is traceable to a commit.

• medium deployment Unpinned base image and dependencies installed at runtime

  Evidence: deploy.md:78 imagePath `docker.io/library/node:24-alpine` (tag only, no @sha256 digest); app/deploy/start.sh line 5 runs `npm ci --omit=dev` on every container start, so each restart fetches packages from the npm registry. A package-lock.json is included in the tarball.

  Fix: Pin the base image by digest and install dependencies once at build time (a Dockerfile or the native build step), not on every start.

• medium deployment Commercial app hosted on Render free tier that sleeps when idle

  Evidence: process/context.json `use: commercial`; process/resources.json `plan: free`; deployment.json notes: 'Free-tier instances spin down when idle, so the first request after inactivity can take roughly 30-60 s.'

  Fix: Move the service to a paid Render instance type (for example Starter) intended for production, so it stays up and has support.

• low deployment Container runs as root

  Evidence: The service uses the stock node:24-alpine image (defaults to root) with dockerCommand `sh /etc/secrets/start.sh` (deploy.md:183). It extracts to /srv/app and runs node without dropping privileges.

  Fix: Run as the image's `node` user (a USER directive in a Dockerfile) and use a writable directory that user owns.

• low app Missing security headers

  Evidence: `curl -sI https://adb-ysjix-dataviz-web.onrender.com/` returns no strict-transport-security, x-content-type-options, x-frame-options/frame-ancestors or content-security-policy headers. app/app.js sets no headers.

  Fix: Add helmet (or set the headers manually) with HSTS, nosniff, frame-ancestors 'none' and a restrictive CSP. The inline script and style in index.html will need to be accounted for.

• low app X-Powered-By banner discloses framework

  Evidence: Response header `x-powered-by: Express` on GET /; unknown paths return Express's default 'Cannot GET /...' page.

  Fix: Call app.disable('x-powered-by') and add a custom 404 handler.

• low app No rate limiting on public API

  Evidence: app/app.js: /api/summary and /api/orders (up to 500 rows per request) have no rate limiting or caching.

  Fix: Add a lightweight rate limiter (for example express-rate-limit) or rely on a CDN or WAF rule.

• info app Array-style query parameters are silently ignored

  Evidence: GET /api/summary?region[]=a returned 200 with all 2400 orders (app/app.js parseQuery accepts only strings).

  Fix: Return 400 for non-string filter values so callers know their filter wasn't applied.

• info deployment API key handled only through environment variable

  Evidence: deploy.md:4 lists env names only (`env | cut -d= -f1`); every API call uses `Authorization: Bearer $RENDER_API_KEY`. No [REDACTED] values appear in any output.

  Fix: None required. Note that the secret-file feature was used to carry code, not credentials.

Cloud resources and cost

Resources the agent created

The agent estimated $0.00 a month.

Code

Code

337 lines in 11 files (JavaScript 240, HTML 91, JSON 35, Markdown 11, YAML 8, Shell 6)

Dependencies

2 npm, 0 Python

Deploy config

render.yaml

The agent's sessions

The agent's deploy summary

Raw data

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