Vibe coding means letting AI agents ship features in minutes, judged on whether the thing looks like it works rather than whether it is safe. The speed is genuinely useful. What worries me is the debt underneath it: vibe coding security risks that nobody notices until somebody outside the team finds them first.
I have worked in the WordPress ecosystem for 14 years, so speed hacks are not new to me. This one lands differently. The security firm Wiz reported on Moltbook, an AI-agent social network that leaked 1.5 million API keys through a misconfigured database. Nobody involved was malicious. They were vibe coding: they optimized for getting the code to run and never checked what else it did.
Why agents pick speed over safety
Large language models are built to be helpful. Ask an agent to fix a “Permission Denied” error and the shortest route to a working state is often to delete the permission check. To the model, a security wall is a bug standing between it and a green result. That is a large part of why your custom plugin fails WordPress security standards when an agent writes all of it.
1. The exposed API key trap
A client sent me their “AI-optimized” WooCommerce integration to review. The agent had dropped an OpenAI secret key straight into a JavaScript file so the fetch call would be simpler. Keys never belong in the front end. If it ships in the JS, anyone who opens Inspect Element can spend your credits.
// THE BAD AI WAY: Hardcoded in frontend
const response = await fetch('https://api.openai.com/v1/...', {
headers: {
'Authorization': 'Bearer sk-proj-12345...' // EXPOSED!
}
});The safe route is wp_localize_script or a REST endpoint that hands data down from the backend. Better still, keep the key in a server environment variable so it never reaches the browser at all.
2. The “public access” database fallacy
Agents reach for wide-open policies. I see it most with custom REST routes, where the agent drops permission_callback because it was throwing a 403. The 403 goes away and your private data turns into a public buffet.
<?php
// THE BAD AI WAY: No permission check
add_action( 'rest_api_init', function () {
register_rest_route( 'my-plugin/v1', '/user-data/', array(
'methods' => 'GET',
'callback' => 'bbioon_get_private_data',
'permission_callback' => '__return_true', // SECURITY DEBT!
) );
} );How to cut down vibe coding security risks
None of this means dropping AI assistants. It means not trusting them on faith. The OWASP Top 10 still puts broken access control and cryptographic failures near the top of the list, which is exactly where agent code tends to break. My review routine is short.
- Prompt with the spec, not the symptom. Instead of asking for a fix, ask for the function written to WordPress security standards, with nonce checks and
wp_kseson anything that gets printed. - Read agent code the way you would read a pull request from an intern who has never seen your codebase. The model cannot see the side effects, so somebody else has to.
- Let a scanner catch the secrets. GitGuardian or a CI/CD check of your own will flag a hardcoded key before it ships. I wrote more about where the standards are heading in fixing core security bloat.
If chasing this stuff is eating your dev hours, I can take it off your plate. I have been wrestling with WordPress since the 4.x days.
Verify the diff before you ship
AI speeds up the typing but supplies no judgment. It matches patterns without understanding what they imply. Ship on vibes instead of validation and you end up maintaining a liability rather than a product. Keep the official WordPress security docs open and read the diff before it merges.
