Website security in the age of AI. WordPress, Joomla, WooCommerce or vibe coding?

Website security in the age of AI is not a matter of one CMS — it is the sum of many decisions. You cannot judge a website's security by the CMS alone. WordPress can run stably for years, yet a single neglected plugin can open the door to an attack. An app built with Lovable may not have classic plugins, but poorly configured database permissions can still expose data.

Does AI increase the threat to websites?

Two things happen in parallel. Attackers use automation to discover vulnerable sites faster, generate malware variants, run phishing at scale and hammer login forms. Builders use AI to ship code faster — but speed of creation does not imply correctness or security.

Vibe coding is a way of building software where you describe the goal in natural language and a model generates and modifies the code. Human responsibility shifts from writing every line to specifying, testing, reviewing and approving. Current research shows benefits for prototyping, but limited evidence for long-term maintainability and high-security use cases.

WordPress — is the CMS the problem, or its surroundings?

WordPress core vs. plugins and themes

Instead of claiming "WordPress is insecure", look at the full dependency chain:

• WordPress core,
• theme,
• plugins,
• custom code snippets,
• PHP and the database,
• hosting configuration,
• admin accounts,
• backups,
• CDN and firewall,
• devices used by site managers.

Official WordPress docs point to updating core, plugins and themes, and picking extensions that are still actively maintained. They also recommend strong authentication, correct file permissions, backups, event logging and monitoring.

Why plugins expand the attack surface

Any plugin can expose a new API endpoint, process user input, run database operations, write files, add accounts or roles, talk to external systems and schedule background jobs.

Most common owner mistakes

Plugins and server load

It is not just about the number of plugins. One badly written plugin can strain the server more than a dozen simple ones. Watch: SQL query count and time, PHP memory usage, PHP process count, cron jobs, admin-ajax.php calls, REST API, outbound requests, report generation, security scans, backups, search and filters.

A telling example is WooCommerce.com itself. The team described a mechanism for selectively loading plugins on specific routes, because loading the full plugin set on every request increased response time, memory usage and operations. The problem is rarely the raw number of add-ons — it is the cost of running them for a given request.

Joomla — a smaller ecosystem is not a risk-free one

Extensions and version compatibility

For Joomla, look at: components, modules, plugins, templates, page builders, custom overrides, and extension compatibility with new Joomla and PHP versions.

Official Joomla guidance covers regularly updating the CMS, PHP, the database engine and all extensions. The docs also recommend checking extensions against the vulnerable-extensions list before installing, and testing carefully after security configuration changes.

The problem of older Joomla installs

What a strong Joomla recovery case study should contain

Instead of "I removed the virus", a strong case study shows the process: initial situation (Joomla version, install age), attack symptoms (redirects, SERP spam, new accounts), first diagnosis, likely entry point (only if confirmed), how the site was recovered without publishing details that would help attackers, issues encountered (no clean backup, re-infection), the outcome, hardening applied afterwards, and — if disclosable — time and cost.

WooCommerce deserves separate analysis

WooCommerce should not be treated as just another plugin. A shop handles customer data, orders, payments, inventory, documents, logistics integrations and automated processes.

Minimum requirements are not an optimal server

Current WooCommerce recommendations list PHP 8.3 or newer, MySQL 8.0 or MariaDB 10.6, HTTPS and a WordPress memory limit of at least 256 MB. That is a starting point, not a recommendation for a large store.

Official scaling docs note performance depends on traffic patterns, WooCommerce code, the theme and other plugins, server infrastructure, product/order/operation counts, and the quality of the team maintaining the shop.

What actually loads a large shop?

• concurrent user sessions,
• cart, account and order pages that cannot be simply cached,
• variable products,
• filtering and search,
• inventory sync,
• imports and exports,
• ERP, CRM and courier integrations,
• document generation, webhooks, Action Scheduler jobs,
• campaigns causing traffic spikes,
• bots and automated scanners.

Action Scheduler handles recurring payments, webhooks, emails and other background operations. At scale, its queue, errors and execution time need dedicated monitoring.

Database and HPOS

High-Performance Order Storage writes order data into dedicated tables instead of WordPress wp_posts/wp_postmeta. It improves scalability, reliability and query performance — but on an existing shop it requires plugin compatibility checks and a controlled migration.

Cost of a large WooCommerce

The most useful numbers come from real projects — or three anonymised bands: small shop, growing shop, high-traffic shop.

Vibe coding and Lovable — what really changes?

No plugins does not mean no dependencies

The app may not have a panel with dozens of plugins, but it still uses JavaScript libraries, database services, authentication, server functions, APIs, payment gateways, hosting, email systems and AI-generated code. The visible number of add-ons drops — the number of technical dependencies does not necessarily.

Key Lovable security areas

Official Lovable docs emphasise that secrets and private keys must not live in frontend code — code running in the browser is accessible to the user. Sensitive operations belong on the server (for example in Edge Functions), and data access should be controlled by Row Level Security (RLS).

Review: authentication and authorisation, RLS rules, secrets and env vars, input validation, admin permissions, integrations with external systems, webhook handling, logs and monitoring, database backups, ability to export and keep evolving the code, and dependence on the platform and providers.

Security has to be a process

What does a Lovable-built site or shop cost?

Break the cost into four phases — not a single build price.

1. 1 stycznia 2001
   Prototype

   UI design, prompts and iterations, basic data models, first integrations. Lovable can meaningfully accelerate this phase.

2. 1 lutego 2001
   Production readiness

   Reviewing generated code, cleaning up components, data access rules, error handling, environments, monitoring, security and performance tests. This phase is often missing from price comparisons.

3. 1 marca 2001
   Integrations and migration

   Products and customers, historical orders, payments, shipping, invoicing, ERP or CRM, analytics, SEO and redirects.

4. 1 kwietnia 2001
   Maintenance

   Plan or usage-based costs, database and hosting, library updates, further development, monitoring and incident response, access to someone who understands the architecture.

Lovable's official pricing combines plan cost with credits used during building, and parts of Lovable Cloud and AI usage can generate additional consumption. Do not compare just the monthly plan price to WordPress hosting.

WordPress, Joomla, WooCommerce, Lovable — comparison

Is vibe coding a good alternative?

WordPress or Joomla remain the rational choice when a company primarily needs a content site, easy editing, a proven ecosystem and availability of contractors.

WooCommerce remains a solid choice for many standard shops, but at large scale its cost cannot be reduced to hosting plus a handful of plugins.

Lovable can be the better option for a custom shop or app — if the project is run like a normal software delivery: with architecture, code review, tests, database hardening and a maintenance plan.