Back to Blog
Lesson 39 of the Cloudflare: Cloudflare for Developers: DNS to CDN course
Cloud NativeAugust 17, 20264 min read

Project Milestone: Final Production Audit for Cloudflare Apps

Master the final production audit for your Cloudflare app. Learn to verify security rules, optimize performance, and ensure your deployment is production-ready.

CloudflareDevOpsProductionAuditPerformanceSecurity
Close-up of a hand writing a checklist in a notebook, symbolizing productivity and organization.

Previously in this course, we covered Performance Auditing to establish a baseline for your application's speed. Now, we reach the final hurdle: a holistic, end-to-end production audit.

You've built a robust system using Workers, R2, and D1. However, "it works on my machine" (or even in a staging environment) is not the same as being "production-grade." A professional production audit ensures that your security, data integrity, and performance metrics aren't just good enough—they are hardened for the public internet.

The Three Pillars of a Production Audit

To verify your deployment, we focus on three core areas: Security, Data/State, and Efficiency.

1. Security Rules Verification

Before going public, you must confirm that the protections we implemented in Project Milestone: Securing the Full Stack with Cloudflare are active and correctly ordered.

  • WAF Rule Audit: Check the "Security > WAF" dashboard. Are your custom rules enabled? Ensure you haven't left any "Log" mode rules that should be in "Block" mode.
  • Security Headers: Use a tool like securityheaders.com to verify your Content-Security-Policy and Strict-Transport-Security headers.
  • Secret Rotation: Ensure no hardcoded credentials exist. Verify that all sensitive tokens are managed via wrangler secret.

2. Data Integrity and State

With your D1 database and R2 storage, the audit must confirm that your application handles state predictably.

  • Migration Status: Run wrangler d1 migrations list <DATABASE_NAME> to ensure the remote state matches your local schema.
  • R2 Public Access: If you are serving assets from R2, verify that the bucket's public access is restricted to your Worker's domain or specific signed URLs, preventing unauthorized direct access to your storage costs.

3. Production-Grade Performance

We previously analyzed TTFB, but now we confirm your application behaves well under real-world conditions.

  • Cache Hit Ratio: Navigate to the "Analytics & Logs" tab in your dashboard. Check if your cache hit ratio is above 80% for static assets. If it’s low, investigate your Cache Rules to see if you are accidentally bypassing the edge.

Worked Example: The Audit Checklist

Close-up of tax preparation checklist and income statement with paperclips.

As a senior engineer, I never perform an audit without a checklist. Run these commands or checks against your current project:

Bash
# 1. Verify D1 migrations are up to date
npx wrangler d1 migrations list <YOUR_DB_NAME>

# 2. Check current environment secrets (ensure no missing keys)
npx wrangler secret list

# 3. Test a protected endpoint with a fake token
curl -I -H "Authorization: Bearer invalid-token" https://your-app.com/api/secure-data
# Expectation: 401 Unauthorized

If the curl command returns a 200, your authentication middleware is failing—this is a critical finding that must be addressed before the project is considered "live."

Hands-on Exercise

Perform the following validation steps:

  1. The "403" Test: Attempt to access your API from a blocked country (or use a VPN to simulate a restricted IP) if you have WAF rules configured for geographic blocking.
  2. The "Empty State" Test: Clear your D1 table (in a staging instance) and ensure the frontend handles the empty data gracefully instead of throwing a 500 error.
  3. The "Header Scan": Inspect your production response headers in the browser Network tab. Confirm cf-cache-status is HIT for your static assets and MISS for dynamic API requests.

Common Pitfalls

  • Environment Drift: The most common production failure is having different secrets or D1 bindings in local dev versus production. Always use wrangler.toml environments to keep configurations distinct.
  • Ignoring Logs: Relying solely on dashboard metrics. Use wrangler tail to watch production traffic in real-time during your audit to catch errors that don't trigger alerts.
  • Over-Caching: Setting a long TTL for dynamic API responses. If your data changes frequently, ensure your API endpoints have Cache-Control: no-store or that you have a purge strategy ready.

FAQ

Q: How often should I perform this audit? A: Perform a full audit before every major release or whenever you modify your WAF or infrastructure bindings.

Q: Does "Production-Grade" mean 100% uptime? A: No, it means you have the observability and error-handling in place to detect and recover from issues quickly, as discussed in Error Handling and Alerts.

Recap

Team members presenting a project in a modern office setting with a focus on collaboration.

A professional production audit is your final safeguard. By verifying your WAF rules, checking data migration status, and confirming optimal cache behavior, you ensure that your application is resilient and secure. Don't skip the manual testing phase—automated tools are great, but your eyes on the browser network tab are the final authority.

Up next: We will learn to manage cross-origin traffic by configuring CORS headers in your Workers.

Similar Posts