Vibe Coding Infrastructure: The Same App Scored 54/100

Quick answer: infrastructure is the pillar most founders assume is already handled, because a hosting platform is involved and hosting platforms feel like they should own this. They own the server. They don't own your DNS records, your TLS configuration, or what your server volunteers about itself to anyone who asks. In the same real app we've been covering in this series, the one that scored 100 on performance and 70 on security, the infrastructure pillar came back at 54 out of 100.

If you're catching this series mid-stream: real app, built fast with an AI coding tool, run through a free FlawPilot scan that checks security, performance, infrastructure, and SEO. The first post covered security, the second covered SEO. This one is infrastructure, the pillar with the most "wait, isn't that the host's job" findings on it.

The scorecard, one more time

67 out of 100 overall, four pillars, infrastructure the second-weakest:

• Security: 70/100. Needs attention. 16 findings.
• Performance: 100/100. Excellent. Zero findings.
• Infrastructure: 54/100. At risk. 10 findings.
• SEO & Discoverability: 46/100. At risk. 9 findings.

Infrastructure sits in an odd spot psychologically: it's the pillar most likely to get waved off with "that's handled," because a platform is clearly involved in serving the app. The findings underneath it say otherwise.

What was actually sitting there

Any certificate authority could have issued an SSL certificate for the domain. No CAA (Certification Authority Authorization) record existed to say otherwise. A CAA record is a short DNS entry that names which certificate authorities are allowed to issue certs for a domain. Without one, the field is open: any CA that gets tricked or compromised can issue a valid cert for the domain, and browsers will trust it without complaint. It's a single DNS line, and it was never added.

Outgoing mail had no signature to vouch for it. No DKIM record, meaning nothing cryptographically ties outbound email to the domain that supposedly sent it. Combined with the missing DMARC record already covered in the security half of this report, mail from this domain was landing in spam more often than it should, and had no defense against being spoofed either.

The server was telling anyone who asked exactly what it was running. An HTTP response header disclosed the exact server software and version, a small, specific, free gift to anyone searching for a matching exploit that week. Nobody built this on purpose. It's what a default configuration hands out unless someone turns it off.

Those three are named, direct findings from this app's own report. The other seven on the infrastructure pillar weren't itemized here individually, but they're the shape we see repeatedly on apps built this way: unnecessary ports left open and reachable from the internet, no WAF sitting in front of the app to catch obvious attack patterns, TLS configured with the platform's default cipher suite rather than anything hardened, and DNS hygiene gaps, stale subdomains or records pointing at services that no longer exist, that create a small but real subdomain-takeover surface.

The "the host handles it" assumption

This is the pillar where that assumption does the most damage, because it's half true. Your hosting provider does handle real infrastructure security: the physical servers, the network layer, DDoS protection at the edge, patching the operating system underneath your app. What it doesn't handle is anything that's a decision about your domain and your configuration rather than their infrastructure: your CAA policy, your DKIM key, whether your server's software banner is suppressed, whether a WAF sits in front of your specific app.

That line is exactly where "my hosting provider handles security" quietly turns into a gap nobody owns. The provider secured everything on their side of the line correctly. Nothing on your side of it was ever anyone's job, because it was never anyone's job description.

Why this is the default, not a fluke

None of these findings show up by using the app, which is exactly why they survive. A missing CAA record doesn't break a page load. A DKIM gap doesn't stop an email from being sent, it just makes it more likely to land in spam or get spoofed, quietly, with no error message pointing at the cause. A visible server banner doesn't do anything to the app at all, until it does something to the attacker trying to find one.

AI coding tools and their default hosting paths are optimized for "the app is live and reachable," which is a real, achieved outcome, not a false promise. DNS-level hardening and response-header hygiene were never part of that job, because they're invisible to the exact kind of manual testing (clicking through screens, checking that pages load) that catches everything else. The gap isn't a bug in the tooling. It's a category of risk that doesn't announce itself.

Found it. Now what?

Same structure as the rest of this report: findings grouped by area, dropped into a ranked "What to do next" list, plain English instead of a field name. The CAA fix reads as add a CAA record to your DNS so only your intended certificate authority can issue certs for your domain. The server banner fix reads as disable the server version header in your platform's configuration. Neither requires touching application code.

That's the pattern across almost everything on this pillar: DNS records and configuration flags, not a rebuild. The CAA record and the server banner suppression are each a few minutes. The DKIM setup is closer to twenty. None of it is a reason to put this off for a quarter.

Your turn

You don't need an infrastructure background to read a report like this one. You need to run the scan.

No setup, no coding, no passwords required. Drop in a URL, and in about two minutes you get the same kind of scorecard back: security, performance, infrastructure, and SEO, each out of 100, every finding in plain English, with a toggle between the founder view and the full technical one.

Your hosting provider is handling more than you'd think, and less than you'd assumed. The only way to know which parts fall on which side is to check.

Scan your site for free →