Your AI-built plugin works, but that does not yet mean it is safe

You had an idea for your website, described it to an AI coding assistant, and an hour later you had a working WordPress plugin. That is a real achievement, and it is exactly how these tools should be used. I use them every day myself.

Seeing it work when you try it answers only one question, though. Once a plugin is live, it has to cope with people who are not you: visitors, other logged-in users, automated bots and, now and then, someone actively looking for a weakness. These are the checks I run first, explained without code wherever I can manage it.

Who is allowed to call it?

Most interactive plugins add endpoints, which are addresses the browser calls behind the scenes (through admin-ajax.php or the WordPress REST API). The question is who is allowed to call them.

AI assistants quite often write endpoints that work for you, because you are logged in as an administrator, but never actually check who is asking. Anything that changes data or reveals it should have two things:

• A capability check. The code should ask WordPress whether the current user is allowed to do this particular thing (whether they can manage options, for example), rather than only whether they are logged in.
• A nonce. This is a one-time token which proves the request came from your own page, and not from a link someone tricked an administrator into clicking.

One quick thing to look for is an AJAX action registered with wp_ajax_nopriv_, which is open to anyone on the internet, logged in or not. Sometimes that is intended, but often it is not.

Is output escaped?

If your plugin shows anything a user typed (a name, a comment or a form field), it has to be escaped before it goes on the page. Otherwise someone can type a script instead of their name, and that script will run in the browser of everyone who views it, your administrators included.

// Risky: prints whatever was stored
echo $entry->name;

// Safer: WordPress turns it into harmless text
echo esc_html( $entry->name );

The same applies to database queries: anything that came from a user should go through $wpdb->prepare() and never be pasted straight into the SQL.

Does it query the database inside a loop?

This is the performance problem I see most often. A plugin lists 50 products and runs a separate database query for each one (or, worse, calls an outside service for each one). On a test site with five items nobody notices, but on a busy page it can mean hundreds of queries per visit, and your hosting starts to struggle long before you expected it to.

It is worth asking what would happen if ten times the usual number of visitors turned up at once, whether anything is cached, and whether every page view calls an external service.

What personal data does it keep, and for how long?

If the plugin stores names, email addresses, IP addresses or form submissions, that is personal data under UK GDPR, so you need to know where it is stored, who can see it, how long it is kept and how to delete it when someone asks. Plugins built in a hurry often keep everything forever, in a custom table nobody remembers is there. WordPress has its own tools for exporting and erasing personal data, and a well-built plugin hooks into them.

Are there secrets in the code?

API keys for email services, payment providers or AI tools sometimes end up written straight into the plugin file. If that file is ever shared, committed to a public repository or exposed by a misconfigured server, the key goes with it. Keys belong in configuration kept outside the code, and they should have only the permissions the plugin actually needs.

Who is going to look after it?

WordPress, PHP and your other plugins are updated all the time. Something that works today can break after a routine update, or a library it relies on can turn out to have a vulnerability. It is worth deciding now who will notice when it breaks, who will apply the fixes, and whether anyone other than the person who built it (or the AI that helped) can understand the code.

Please keep building

None of this means you should stop. I would encourage the opposite: keep using AI, and have the result checked by a person before it carries real traffic or real customer data. Many of these problems take minutes to fix once someone has spotted them.

If you would like a second pair of eyes, our Production Readiness Review is a five-day check, at a fixed price, of something you have already built. You will receive a short report with a red, amber and green summary and the ten fixes that matter most, and we can make the fixes for you if you would prefer. Questions are welcome either way.