We are living in the golden era of “Vibe Coding.” Thanks to advanced LLMs like Claude, GPT-4, and specialized coding assistants, developers can now translate raw human intent into fully functioning software in a matter of minutes. You feed an idea to an AI, review the visual layout, request a few adjustments, and “vibe” your way directly to a live, deployed application. It is an incredibly empowering shift that has shattered the barrier between conceptualization and production.
But there is a dangerous side effect to this newfound speed. While AI models are spectacular at writing application-level logic, rendering beautiful modern interfaces, and solving local algorithmic puzzles, they have a massive, systemic blind spot: infrastructure-level security and web deployment hardening. Because AI engines generate code based on context windows focused heavily on components and immediate functionality, they rarely think to remind you to configure server environment variables, establish strict cross-origin boundaries, or append robust security headers to your HTTP responses.
To understand exactly how this blind spot manifests—and how to fix it—we will dive deep into a real-world case study of an AI-coded application, tracking its transformation from visually pristine but structurally exposed to enterprise-grade secure.
A React 19 Markdown-to-PDF Tool
The subject of our analysis is a production-ready utility application: a Markdown to LaTeX/PDF Generator hosted at https://markdown-pdf-self.vercel.app/.
Architecturally, this app represents a classic, high-performance modern client-side frontend:
-
The UI Core: Built on React 19 and Vite, utilizing a highly polished, Apple-inspired “Liquid Glass” UI. It relies heavily on backdrop filters (
backdrop-filter: blur(20px)) and CSS variables to handle real-time transitions between light and dark modes over a mesh gradient background.
-
The Text Engine: Driven by
Marked.js as the core Markdown parser to translate raw user inputs into structured HTML.
-
The Math & Code Ecosystem: Extended via
Highlight.js for programming language syntax highlighting and KaTeX for real-time, mathematical typesetting (e.g., rendering equations like $E=mc^2$).
Because this application was built to ingest markdown text that may come directly from chat interfaces, a clever feature was implemented inside a React useMemo hook: an “AI Bracket Fixer.” Large Language Models frequently emit messy, inconsistent math delimiters when outputting formulas (such as mixing up single $ symbols with double $$ blocks or escaping brackets in ways that confuse compilers). The application pipes raw user text through a specialized regex pipeline to automatically clean and normalize these boundaries before passing them to the KaTeX renderer. It’s a perfect example of a modern application designed explicitly to work hand-in-hand with AI outputs.
The client-side logic was flawless, the editor was responsive, and the PDF printing engine worked natively and beautifully via an optimized @media print layout in styles.css. However, when this “vibe-coded” application was deployed to the cloud and subjected to an automated security audit, the results revealed a stark division between frontend aesthetics and infrastructure perimeter security.
Baseline Audit: Visually Perfect, Structurally Exposed
The initial external application security scan returned an alarming Overall Security Score of 50/100.
While the application achieved perfect marks for its TLS/SSL implementation (supporting only TLS 1.2+ with modern forward-secrecy cipher suites) and successfully locked down its environment files, it failed completely on the web network perimeter: HTTP Security Headers.
By default, standard serverless edge networks like Vercel serve raw web assets with extreme efficiency, but they do not attach explicit security rules to response envelopes unless explicitly instructed. The AI engine generated the React code flawlessly but left the deployment configuration entirely stock. This omission introduced several critical vulnerabilities:
| Security Check |
Result |
Severity |
The Real-World Vulnerability & Exploit Vector |
| Content-Security-Policy (CSP) |
FAIL |
High |
Cross-Site Scripting (XSS): The browser had no instructions regarding which domains were trusted to load executable code. If an attacker managed to inject a malicious script via an input payload or a compromised third-party package, the browser would run it unconditionally, risking session hijacking or data leakage. |
| X-Frame-Options |
FAIL |
High |
Clickjacking Attacks: Lacking this header, any malicious third-party website could embed the Markdown-to-PDF tool inside an invisible HTML <iframe>. Attackers could overlay deceptive buttons directly over the actual editor, tricking users into clicking elements on the app without their knowledge. |
| X-Content-Type-Options |
FAIL |
Medium |
MIME-Type Sniffing: Without the nosniff directive, web browsers might ignore the declared Content-Type of an asset and attempt to guess its format based on its contents. An attacker could find a way to make the app fetch a malicious script disguised as a plain text or image file, which the browser would then execute. |
| Server Header Disclosure |
FAIL |
Medium |
Technology Stack Information Leakage: The server headers openly broadcasted Server: Vercel. While hosting on Vercel is highly secure, providing an explicit technological footprint helps malicious actors map your exact software stack and research tailored exploits. |
| Referrer & Permissions Policies |
FAIL |
Med/Low |
Information Leaks & Unrestricted Access: Outbound link clicks could leak internal URL query structures to external analytics platforms. Furthermore, the browser was not explicitly barred from accessing client hardware like the camera, microphone, or geolocation APIs. |
The Vibe Coding Trap
AI models excel at what you show them in the viewport. They focus on the components, state hooks, and style layouts you interact with directly. They do not naturally consider the invisible, server-side HTTP handshake happening between the web browser and your cloud provider’s edge node. That oversight is exactly where vulnerabilities hide.
Infrastructure Hardening
To rectify these vulnerabilities, there is no need to modify or rewrite a single line of your React application logic. Instead, the hardening must be applied at the infrastructure configuration layer.
On serverless hosting networks like Vercel, this is accomplished by introducing a declarative configuration file—vercel.json—at the absolute root of your project repository. This configuration forces the cloud server’s edge nodes to inject explicit, protective headers into every outbound HTTP asset transmission.
Here is the exact production-ready configuration file deployed to seal the architectural gaps highlighted in the baseline audit:
{
"headers": [
{
"source": "/(.*)",
"headers": [
{
"key": "Content-Security-Policy",
"value": "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self'"
},
{
"key": "X-Frame-Options",
"value": "DENY"
},
{
"key": "X-Content-Type-Options",
"value": "nosniff"
},
{
"key": "X-XSS-Protection",
"value": "1; mode=block"
},
{
"key": "Referrer-Policy",
"value": "strict-origin-when-cross-origin"
},
{
"key": "Permissions-Policy",
"value": "camera=(), microphone=(), geolocation=()"
}
]
}
]
}
Breaking Down the Security Injection:
-
Content-Security-Policy (CSP): Rigorously confines asset execution. Declaring
default-src 'self' prevents the browser from loading unauthorized remote scripts. It accommodates modern single-page frontend frameworks by safely allowing 'unsafe-inline' and 'unsafe-eval' (which are necessary for client-side routing, compilation, and KaTeX math processing), while guaranteeing that image boundaries (img-src) and network fetch destinations (connect-src) remain strictly enclosed.
-
X-Frame-Options: DENY: Completely cuts off framing capabilities, neutralizing clickjacking threats instantly. No foreign origin can encapsulate this user interface.
-
X-Content-Type-Options: nosniff: Forces the browser to strictly follow the MIME-types provided in the network response, shutting down content-type sniffing vectors.
-
Permissions-Policy: Implements the Principle of Least Privilege at the browser hardware layer. By explicitly setting empty restrictions for
camera=(), microphone=(), and geolocation=(), the application signals that it has no business requesting sensitive hardware permissions, establishing deep trust with privacy-conscious users.
The Post-Remediation Posture: 100% Perimeter Defended
Following the deployment of the root-level vercel.json file, a secondary automated compliance audit was triggered. The application’s Overall Security Score jumped from a failing 50 up to a highly secure 84/100, and the critical HTTP Security Headers category achieved a perfect 100/100 pass rate.
However, a closer look at the remaining minor scanner notifications provides a vital lesson in balancing academic compliance checklists with practical real-world application engineering.
The Security vs. Performance Tradeoff (Cache-Control)
The security scanner still flagged a warning on the Cache-Control header because it utilized a standard static caching layout (public, max-age=0, must-revalidate) instead of a strict no-store policy.
In a heavy, full-stack application dealing with financial ledgers, medical records, or user authentication sessions, no-store is a non-negotiable requirement to prevent shared proxies from caching private data.
However, this Markdown-to-PDF tool is a purely client-side utility. It features no backend servers, no user data tables, and transmits no private user tokens over the wire. For an open static frontend, enforcing a strict no-store policy would destroy application performance. Browsers would be barred from local asset caching, resulting in sluggish load speeds, higher data consumption, and increased rendering latency on every single refresh—offering absolutely zero security benefit in return. Maintaining standard static caching was an intentional, correct engineering tradeoff.
Filtering Compliance Noise
Automated security tools evaluate applications against generic compliance matrices. The secondary report noted several informational flags under categories like Database Security (demanding parameterized queries and VPC network separation) and Credential Handling (requiring Argon2 password hashing and session invalidation middleware).
Because our architecture has no database tier, no login forms, and no stateful backend sessions, these metrics are completely non-applicable. Securing an AI-coded application means understanding your architecture well enough to separate critical, exploitable perimeter vulnerabilities from automated compliance noise that does not apply to your stack.
The AI Coder’s Actionable Security Checklist
If you are building and deploying software using AI orchestration tools, you must add an independent validation phase to your deployment loop. Use this four-step checklist to secure your applications before pushing them live:
- [ ] Harden the Edge Hosting Layer: Never assume your cloud provider’s default state is production-ready. If deploying a frontend application to Vercel, Netlify, or Cloudflare Pages, always include a dedicated configuration file (such as
vercel.json or _headers) to explicitly inject security headers (CSP, X-Frame-Options, X-Content-Type-Options).
- [ ] Sanitize and Control Untrusted Inputs: AI-generated outputs can be unpredictable. If your application acts as a downstream consumer of LLM tokens (such as an editor digesting copy-pasted or API-piped text), implement structural sanitization steps—like the custom regex “AI Bracket Fix” to clean equations, or a library like
DOMPurify to scrub HTML before rendering it inside the browser.
- [ ] Minimize Information Leakage: Strip verbose architecture details from your deployment metadata. Suppress or modify response headers that disclose underlying platforms (like
Server or X-Powered-By) to avoid handing attackers an exact map of your technology stack.
- [ ] Audit Reports with Common Sense: Use automated scanning tools to expose genuine architectural gaps, but verify their findings against the reality of your application’s design. Do not degrade application load times or break framework performance metrics to check a box for a database compliance rule if your application runs entirely on the client side.
Conclusion
AI allows us to write and deploy code at an extraordinary pace, but it does not relieve us of our responsibility to protect our users. “Vibe coding” is a phenomenal mechanism for rapid feature prototyping and creative execution, but the final architectural hardening phase still requires human engineering oversight. Spend ten minutes auditing your infrastructure files, secure your network handshakes, and ensure that your lightning-fast deployments are as safe as they are beautiful.
Build fast, but build secure.
