RENDER SECURITY CHECKLIST

Render’s distinction between Web Services (public) and Private Services (internal-only) is the single most security-relevant choice you make on the platform — and it’s the one most teams get wrong. Backend services that should be private get deployed as Web Services because that was the default option in the wizard. The result: internal APIs reachable from the public internet, sometimes without auth. The checklist below is what we look for first when we audit a Render deployment.

Treat Critical as launch-blocking. High is week-one. Medium is the cleanup once you have users.

How to use this checklist

Walk it once in the Render dashboard for your production project, ticking items as you go. Audit each service type (Web, Private, Background Worker) separately. After the whole list passes, run a black-box scan against the production domain.

Critical (fix before launch)

1. Use Render environment groups scoped to services that need them

Why it matters. Environment groups in Render are reusable bundles of env vars. Convenient, and a security risk if a group with secrets gets attached to a service that doesn’t need them. We have audited cases where an env group meant for the API service was also attached to a static site, exposing API secrets at build time.

How to check. Env Groups. For each group, list the services it’s attached to. Cross-reference against what each service actually needs.

How to fix. Create per-service or per-tier groups. Detach groups from services that don’t need them. Rotate secrets that ever sat in over-broad groups.

2. Enable IP allowlisting on databases

Why it matters. Render PostgreSQL and Redis have public hostnames by default, with bearer-token (connection string) auth. Without IP restrictions, anyone with the connection string can connect from anywhere — and connection strings end up in env files, in build logs, and in chat transcripts.

How to check. For each database, check the access controls. Confirm the public endpoint is restricted to specific IPs, or use private networking exclusively.

How to fix. Restrict the public endpoint, or disable it entirely and route traffic via Render’s private network.

3. Configure private services for backends — public defaults expose internal APIs

Why it matters. A Web Service in Render is reachable at <name>.onrender.com. If your “internal” API is deployed as a Web Service (because that’s what the wizard suggested), it’s now public. Combined with weak or missing auth (because “it’s internal”), that’s the breach.

How to check. List every service type. Backend APIs that talk only to other Render services should be Private Services. If they’re Web Services, they’re public.

How to fix. Recreate as Private Services, or restrict the Web Service via auth + IP allowlist. For migrations, change service type and update inter-service URLs.

4. Audit deploy hook URLs for least-privilege use

Why it matters. Deploy hooks are URLs that trigger redeployment. Anyone with the URL can deploy, eating your build minutes and potentially shipping stale or attacker-influenced builds.

How to check. Service → Deploy Hooks. List every hook; identify which service uses each.

How to fix. Delete unused hooks. Rotate any hook shared in PR descriptions, Slack threads, or vendor emails.

5. Move secrets to Render env, not source code

Why it matters. Secrets committed to the repo are visible in the build process and in any container image artifact. Render env vars are encrypted at rest and only injected at runtime.

How to check. gitleaks detect --source . and trufflehog filesystem . on the repo. Search build logs in Render for echoed secrets.

How to fix. Move every secret to Render env. Rotate any secret found in the repo.

6. Configure custom domain SSL and HSTS

Why it matters. Render provides automatic SSL on .onrender.com and on custom domains. HSTS is opt-in; without it, users can be downgraded to HTTP via active network attacks.

How to check. For each custom domain, confirm SSL is provisioned and HSTS headers are set in your app.

How to fix. Enable HSTS via response headers in your app. For sub-domains, use includeSubDomains carefully.

High (fix in the first week)

7. Pin runtime versions in render.yaml

Pin Node/Python/Ruby version explicitly in render.yaml or service settings. Auto-upgrades through major versions can change crypto and HTTP defaults.

8. Restrict shell access to production services

Render’s “Shell” tab gives interactive access to a running service. Restrict the team members who can use it on production services.

9. Set up health checks that don’t expose internal data

Health-check endpoints are unauthenticated. Return only “alive” — not version strings, not feature flags, not config snapshots.

10. Verify domain DNS is locked

Custom domains use DNS records you manage. Audit who can change them at the registrar.

11. Set up build-time secret scanning

Add gitleaks to your build command. Fail the build if a secret is detected.

12. Restrict who can change env vars

Production env changes should require approval. Audit who has write access.

Medium (fix when you can)

13. Configure log retention policy

Render captures stdout/stderr per service. Set retention based on what you actually need; ship to a SIEM if you need longer.

14. Set resource limits per service

Memory and CPU limits prevent a runaway service from consuming the project’s resources or being a noisy neighbor.

15. Document service-to-service auth pattern

How do services authenticate to each other? Service-internal URLs alone are not auth.

16. Audit installed Render Add-ons

Each add-on is attack surface. Audit; remove unused.

17. Set up alerting on deploy frequency

A spike in deploys signals a compromise of a deploy hook or developer account.

18. Pin Docker base images

For Docker-deployed services, pin the base image to a specific digest, not latest. Auto-upgrades are how you ship vulnerable base images.

After every config change

• Re-test public vs private service routing.
• Re-verify env groups haven’t drifted across services.
• Re-test database access from outside the project (should fail).

Common attack patterns we see in Render deployments

The “internal” Web Service. Backend API deployed as Web Service because that was the wizard default. No auth because “internal.” Reachable from the public internet; full database access via the API.

The shared env group. Group containing third-party API keys attached to a static site for “build flexibility”. Build logs echo the env at startup; logs are accessible to anyone with read access on the project.

The leaked deploy hook. Hook URL pasted into a PR description. Attacker triggers builds at will, eats the team’s quota.

The unrestricted database. Render Postgres with public endpoint and no IP allowlist. Connection string leaked in a Sentry breadcrumb; immediately exploitable.

Related Resources

How to Secure Render

Step-by-step guide for hardening a Render deployment — service type selection, env group scoping, database hardening, and the IP allowlisting above in long form.

Is Render Safe?

In-depth analysis of Render’s defaults — what’s locked down, what isn’t, and what we find when we audit a typical Render-deployed app.

Automate Your Checklist

A checklist tells you what to look for. A scanner tells you what’s actually broken in the deployed app right now. VibeEval drives a real browser through your Render deployment, attempts the missing-auth and database-leak attacks above, and reports what got through.