Using AI to Build WordPress Plugins and Shopify Apps Safely

A business owner asks ChatGPT for a Shopify discount rule, or asks Claude for a WordPress plugin that adds a booking form. Code comes back in under a minute, and it may well do what the prompt asked. Getting the code is no longer the hard part. The questions that matter now are where that code lives and who checks it before customers use it.

On WordPress and Shopify, the safest place for AI-written code is the place the platform already provides for outside code: a plugin on WordPress, and an app with extensions or Functions on Shopify. Code there stays a separate package that a developer can review on its own, test and switch off without touching the rest of the site. This guide covers what each platform requires of that code, where AI-written code tends to fall short of it, and how to use AI on a plugin or app without losing control of the site. It expands the “Where AI coding tools fit” section of our guide to website platforms you can start without code and extend later. If you built a standalone app with AI instead, see how a developer takes over an AI-built app.

Using AI for WordPress plugins and Shopify apps: key facts

Question	Answer
Can ChatGPT or Claude write a WordPress plugin or Shopify app?	Yes. A WordPress plugin can be a single PHP file, and Shopify provides its CLI to scaffold apps and Functions. The code still needs the same review as any other code before it runs on a live site.
Where should AI-written code go?	In the platform’s extension points: a plugin on WordPress, an app with theme app extensions or Functions on Shopify. Not in theme files, and never in WordPress core.
Why does the location matter?	A plugin can be deactivated on its own, and when a Shopify app is uninstalled, Shopify removes its theme app code with it. Code spread through a theme has no off switch.
What does WordPress require of plugin code?	Validated and sanitized input, escaped output, nonces on forms and actions, capability checks before anything privileged, and prepared database queries.
Does AI-written code meet those rules?	Not reliably. In a study of 2,500 PHP websites generated by GPT-4, about a quarter contained a flaw an attacker could exploit through the site itself.
Does Shopify review custom apps?	No. Shopify reviews the security of apps listed in its App Store, but custom apps built for one store go through no app review.
Can any Shopify store run a custom app with Functions?	No. Per Shopify’s documentation, custom apps that include Functions only run on Shopify Plus stores.
What does WordPress say about AI-written code?	Its AI guidelines for contributors say to “Treat AI output like code from an unknown external contributor: you must review and validate it before sharing it.”

Why should AI-written code go in a plugin or app?

An AI assistant writes whatever it is asked for, wherever it is asked to put it. Ask for a snippet to paste into a theme’s functions.php file and that is what it produces. Ask for a fix to a Shopify theme template and it edits the template. Each change may work, but after a few months of prompts the site’s custom behavior can end up scattered across files nobody planned, with no record of which lines came from which prompt.

An extension point sets a boundary around the work. On WordPress, a plugin is a named package in its own folder that shows up on the Plugins screen and can be deactivated without touching the theme or other features. Our guide to where WordPress code belongs covers why site features belong in a plugin rather than the theme, whoever writes them.

On Shopify, the boundary is built into the platform. Shopify’s documentation on theme app extensions says apps built that way “don’t edit theme code, which decreases the risk of introducing breaking changes to the theme.” Its Online Store 2.0 overview adds that “When an app is uninstalled by a merchant, the app code is removed with it.” Shopify Functions go further: they run in a sandbox with fixed resource limits, covered below, which caps what any function can do no matter who or what wrote it.

	AI code in an extension point	AI code pasted into theme or core files
Where it lives	One plugin, app or extension with its own files	Spread across files that also hold other code
Turning it off	Deactivate the plugin, or uninstall the app	Find and remove each edit by hand
Reviewing it	A developer reads one package against the platform’s rules	A developer first has to work out which lines were added
Platform updates	Built against documented, versioned interfaces	Theme and core updates can overwrite or break it
Who else can run it	Only what its permissions and scopes allow	Whatever the surrounding file can do

None of this makes the code inside the package safe. It makes the code easier to find, review and remove if something goes wrong.

What does WordPress require of plugin code?

WordPress publishes its security rules for plugin and theme developers in the Security chapter of its Common APIs Handbook, which explains why they matter: “Because WordPress provides so much power and flexibility, plugins and themes are key points of weakness.” Its first principle is “Don’t trust any data,” whether it comes from users, third-party APIs or the site’s own database. The chapter’s guiding principles include “Never trust user input,” “Escape as late as possible” and “Sanitization is okay, but validation/rejection is better.”

In practice, those principles come down to five rules.

1. Validate and sanitize input

Validation tests incoming data against what it should be, such as a quantity greater than zero or one of five allowed options, and rejects anything else. The handbook’s page on validating data says “Data validation should be performed as early as possible,” before the plugin acts on the data. When a field is too open-ended to validate, such as a free-text title, the sanitizing data page shows WordPress’s cleanup functions, like sanitize_text_field(), which strips tags and line breaks.

What to look for in AI-written code: $_POST, $_GET or $_REQUEST values saved or used directly, and validation that exists only in the form’s HTML. The validation page makes the second point with a ZIP code field: a maxlength attribute limits what the browser accepts, but a manual submission can bypass it, so the server checks the length again.

2. Escape output

Escaping makes data safe for the exact place it is printed, so that text from a user or the database can’t run as script in a visitor’s browser. The escaping data page lists a function for each context: esc_html() inside HTML elements, esc_attr() in attributes, esc_url() for links and image sources, and wp_kses() when some HTML should be allowed through. Its advice on timing is direct: “You always want to escape when you echo, not before.”

What to look for: echo statements that print variables without an esc_ function or wp_kses(), and esc_html() used where a URL or attribute needs a different function.

3. Use nonces on forms and actions

A nonce is a token WordPress adds to a form or link so it can confirm the request came from the site’s own page, which protects against cross-site request forgery. The nonces page explains how to add one with wp_nonce_field() and check it with check_admin_referer() or wp_verify_nonce(). It is just as clear about what nonces don’t do: “Nonces should never be relied on for authentication, authorization, or access control. Protect your functions using current_user_can(), and always assume nonces can be compromised.”

What to look for: forms and AJAX handlers that change data with no nonce check, and code that treats a valid nonce as proof the user is allowed to act.

4. Check capabilities before anything privileged

The handbook’s page on user roles and capabilities puts it in bold: “As you build a plugin, make sure to run your code only when the current user has the necessary capabilities.” A capability is a specific permission, such as manage_options for changing site settings, and current_user_can() checks it.

Custom REST API endpoints need particular care. WordPress’s guide to adding custom endpoints says “You must also register a permissions callback for the endpoint,” and advises that “instead of checking if the user is logged in (authentication), check whether they can perform the action (authorization).” Since WordPress 5.5, an endpoint registered without a permission_callback triggers a developer notice, and the documented way to mark an endpoint as intentionally public is __return_true. That is the shortest way to make the notice go away, and it also opens the endpoint to every visitor.

What to look for: register_rest_route() calls with __return_true on endpoints that change or reveal private data, permission checks that only test is_user_logged_in(), and AJAX handlers registered with the wp_ajax_nopriv_ prefix, which run for logged-out visitors.

5. Use WordPress functions and prepared queries for the database

The handbook’s page on common vulnerabilities gives a first rule for avoiding SQL injection: “When there’s a WordPress function, use it.” Functions like add_post_meta() handle the query safely. When a plugin needs a custom query, $wpdb->prepare() builds it with placeholders, such as %s for strings and %d for integers, so user input is never pasted into the SQL itself.

What to look for: SQL strings assembled with variables, such as "... WHERE id = " . $_GET['id'], and custom tables or queries for data WordPress already stores, such as posts, users and options.

What does Shopify require of custom apps and Functions?

Shopify’s model is different from WordPress’s. Custom code lives in an app the store installs. An app can include server code that the developer hosts and that calls Shopify’s APIs, as well as extensions and Functions that Shopify hosts and runs itself. The requirements depend on which kind of app it is and where its code runs.

Custom apps skip Shopify’s app review

Shopify’s distribution guide describes two ways to distribute an app:

	Public distribution	Custom distribution
Who can install it	Any merchant, through the Shopify App Store	One store, or several stores in the same Plus organization, through an install link
App review	Yes	No
Billing through Shopify	Yes	No
Typical use	Apps sold to many merchants	Apps built for one merchant or an agency client

Public apps get a security check. Shopify’s app security requirements state that “Shopify reviews every app’s security before publishing it in the Shopify App Store,” and that “Shopify expects that all third-party applications be protected against common web security vulnerabilities, including but not limited to, The OWASP Top 10.” A custom app built with AI for one store never passes through that review. The merchant and their developer are the only reviewers it gets.

The way custom apps are created has also changed. Shopify’s distribution guide notes that “You can no longer create custom apps in the Shopify admin,” and the Shopify Help Center refers to “legacy custom apps created before January 1, 2026.” New custom apps are built as regular Shopify apps in the Dev Dashboard and given custom distribution. Instructions, including an AI assistant’s, that start by creating an app in the Shopify admin and copying an access token describe the old method.

Scopes, secrets and webhooks

Three requirements apply to almost every custom app’s server code:

• Access scopes. An app declares which store data it can read or write. Shopify’s access scopes documentation says “Request only the data your app needs to function,” and notes that any write scope also grants read access. Generated code that requests broad write scopes for a read-only report is worth questioning.
• The client secret. Shopify’s client credentials guide says to “Keep your Client secret secure,” store it in an environment variable, and “never commit secrets to version control.” The same rules for exposed keys in our AI-built app security checklist apply here.
• Webhook verification. When Shopify notifies an app about an order or other event, each delivery is signed. Shopify’s webhook verification guide says “Always verify HMAC before trusting payload contents,” and each delivery includes an ID the app can use to ignore duplicates. A webhook handler that skips the signature check can be fooled by a forged request.

Shopify Functions run in a sandbox with fixed limits

Shopify Functions customize backend logic during a purchase, such as discounts, delivery options, payment methods and cart validation. Shopify runs them itself, during cart and checkout, so the platform limits what they can do:

Limit	Value
Compiled binary size	256 kB
Runtime linear memory	10,000 kB
Execution instructions (carts up to 200 lines)	11 million
Function input (carts up to 200 lines)	128 kB
Function output (carts up to 200 lines)	20 kB
Input query size	3,000 bytes

Shopify also states that it “doesn’t allow nondeterminism in functions, which means that you can’t use any randomizing or clock functionality in your functions.” Network access is limited to specific cases. Functions can be written in “any language that can compile to WebAssembly (Wasm), although Rust is recommended and strongly preferred,” and Shopify explains why performance matters: “Slow or resource-intensive functions can negatively impact the customer experience and potentially prevent customers from completing their purchases.”

Two consequences for AI-written Functions:

• Plan availability. Per the same page, “Only stores on a Shopify Plus plan can use custom apps that contain Shopify Function APIs.” Stores on any plan can use Functions through public App Store apps, except where an individual Function API says otherwise. Check the store’s plan before asking an AI to build a custom Function.
• Testing against real carts. A function that works on a three-item test cart can run past its instruction limit on a large one. The limits scale for carts over 200 lines, and Shopify shows the calculated limits in the Dev Dashboard and through Shopify CLI.

Shopify’s APIs change every quarter

Shopify’s versioning guide explains that a new API version ships every three months, and “Each stable version is supported for a minimum of 12 months.” It adds that “Shopify CLI prevents deploys targeting versions older than 12 months.” An AI model trained on older documentation can write code for API versions or fields that have since changed or been removed, a pattern covered in AI Code Generation Has a Version Problem.

Where does AI-written plugin and app code fall short?

Published research on AI-generated code doesn’t test WordPress plugins or Shopify apps specifically, but it tests the same kinds of code they contain.

• PHP web code. In LLMs in Web Development, published in the SAFECOMP 2024 workshop proceedings, researchers generated 2,500 PHP websites with GPT-4 and tested them for SQL injection, cross-site scripting and insecure file uploads. They report that “26% had at least one vulnerability that can be exploited through web interaction,” and that file upload code was “insecure 78% of the time.” The sites were standalone PHP rather than WordPress plugins. WordPress’s sanitizing, escaping and query functions exist to prevent these same flaws, but they only help when the code calls them.
• Backend code that works. In BaxBench, a benchmark of 392 backend tasks presented at ICML 2025, the best model tested reached “a mere 62% on code correctness,” and the researchers “could successfully execute security exploits on around half of the correct programs generated by each LLM.”
• Packages that don’t exist. This matters for any app that installs packages, including Shopify apps built on Node.js. A USENIX Security 2025 study, We Have a Package for You!, found that across 16 models, invented package names made up “at least 5.2% for commercial models and 21.7% for open-source models” of the packages referenced, on average.
• Confidence. In a user study published at ACM CCS 2023, Do Users Write More Insecure Code with AI Assistants?, participants with an AI assistant “wrote significantly less secure code than those without access” and were “more likely to believe they wrote secure code.”

These studies tested models released in early 2025 or before, and newer models may score differently. They point the same way, though: code that works can still be exploitable, and the platform rules above cover the cases a quick test doesn’t.

Platform requirement	What to watch for in AI-written code	What a reviewer checks
Sanitize and validate input (WordPress)	Request values used directly, or validated only in the browser	Every $_POST, $_GET and REST parameter is validated or sanitized on the server
Escape output (WordPress)	Variables echoed as-is	Each printed value uses the escaping function for its context
Nonces and capabilities (WordPress)	One check without the other, or neither	State-changing requests check both a nonce and current_user_can()
REST permissions (WordPress)	__return_true used to clear the missing-callback notice	__return_true only on endpoints meant to be public
Prepared queries (WordPress)	SQL built by joining strings	WordPress functions or $wpdb->prepare() everywhere
Minimal scopes (Shopify)	Broad write access requested	Each scope matches a feature the app has
Webhook HMAC (Shopify)	Any incoming request trusted	Signature verified on the raw body, duplicates ignored
Function limits (Shopify)	Tested only on small carts	Tested with large carts and current API versions

How to use AI to build a plugin or app safely

AI can write much of a plugin or app, as long as the process around it is set up to catch what it misses.

1. Ask for the package, not the edit. Prompt for a plugin or an app extension from the start, not for code to paste into a theme. On WordPress, the official @wordpress/create-block tool scaffolds a block as a complete plugin. On Shopify, shopify app generate extension scaffolds extensions and Functions in the structure Shopify expects.
2. Give the AI current documentation. Shopify’s AI Toolkit connects coding agents to Shopify’s docs and API schemas, “rather than relying only on model memory or broad web search,” and can “validate GraphQL queries, Liquid templates, and Shopify Extensions against Shopify schemas to catch issues earlier.” WordPress’s developer handbook pages, including the security pages cited above, link to a Markdown version that can be pasted into a prompt or fed to an agent.
3. Build on a copy, not the live site. Use a staging copy of the WordPress site or a Shopify development store. AI-written code should never be tested first on the store customers are using.
4. Run the platform’s own checks. WordPress.org’s Plugin Check plugin checks a plugin against the directory’s requirements and flags security, performance and accessibility issues. Its description says “Even if you do not intend to host your plugin in the WordPress.org directory, you are encouraged to use Plugin Check so that your plugin follows the base requirements and best practices for WordPress plugins.” The WordPress Coding Standards project provides PHP_CodeSniffer rules that flag unescaped output, missing nonce checks and unprepared queries.
5. Keep it in version control. Commit the plugin or app to a Git repository you own, so every AI-assisted change can be seen, reviewed and undone.
6. Have a person read every line. WordPress’s AI guidelines, written for people contributing to WordPress itself, set a useful bar for any site: “Read every line and remove anything you cannot explain.” The same guidelines say that while AI can assist a review, “human review is required for acceptance into the WordPress project.”

Can you review AI-written plugin code yourself?

Some of it, without being a developer. Open the plugin’s PHP files in a text editor and search for:

• $_POST, $_GET and $_REQUEST. Each one should pass through a sanitize_ function or a validation check before it’s used.
• echo. Variables printed to the page should be wrapped in an esc_ function or wp_kses().
• register_rest_route. Any endpoint with __return_true as its permission_callback is open to everyone.
• $wpdb->query or $wpdb->get_results. The SQL inside should use $wpdb->prepare().
• wp_ajax_nopriv_. These handlers run for visitors who aren’t logged in.

For a Shopify app, read the scopes in the app’s configuration file and confirm each one matches something the app does, and check that the webhook handler verifies the X-Shopify-Hmac-SHA256 header.

A search like this catches the most visible problems, not all of them. Whether a capability check uses the right capability, or a Function holds up on a large cart, still takes someone who reads the code.

When to bring in a developer

AI-written plugins and apps are worth a review before they handle orders, customer data, payments or anything only administrators should be able to do, and whenever one of the searches above turns something up.

Connor on the Web builds and reviews custom WordPress plugins, blocks and themes, including plugins started with ChatGPT or Claude, and the WordPress category collects our other WordPress guides. Our process and pricing are published, and you can get in touch to talk through the plugin or app you’re building.