How the Plugin Works on Every Page Load

Every time someone visits your site, the plugin runs a sequence of checks before the page is served. This happens synchronously — meaning the page cannot load
until the plugin finishes. Under normal traffic this is barely noticeable. Under a bot attack or crawler surge, it becomes a bottleneck.

---
The Core Problem: Writing to the Database During Attacks

WordPress stores its settings in a database table called wp_options. This plugin uses that table for everything — configuration, credentials, status flags, and
activity timestamps.

The critical issue: the plugin writes to this table during ordinary visitor traffic, not just when an admin changes settings.

When a suspicious visitor triggers the fraud detection flow, the plugin can write to the database three separate times in a single page request — all to update a
single status flag that could be computed once and written once. Under a bot surge sending hundreds or thousands of requests per minute, those writes stack up.
Database write operations are expensive and create contention: requests queue up waiting their turn, response times increase, and in severe cases the database
becomes a bottleneck for the entire site.

---
The Autoload Problem: Overhead on Every Page

WordPress has a system called "autoloading" — a list of settings that get fetched from the database every time any page loads, for any visitor. This plugin adds
approximately 17 settings to that autoloaded list, including timestamps and status flags that are only relevant in specific situations.

This means every page request on your site carries the overhead of loading this plugin's data, even for pages the plugin ultimately does nothing with. During a
bot surge, when you might have hundreds of simultaneous requests, every single one of them loads this data unnecessarily.

---
Credentials Stored in Plain Text

The plugin stores its API keys and encryption secrets in the same database table as everything else, with no additional protection. If your database is ever
exposed — through a hosting breach, an unsecured backup, or another plugin's vulnerability — those credentials are immediately readable. An attacker with your
ClickCease credentials could potentially disable the fraud protection silently, or impersonate your site to the ClickCease service.

---
Sensitive Information Sent to External Servers

When certain error conditions occur — which happen more frequently during bot traffic — the plugin logs debugging information and sends it to an external logging
server. That log message includes your encryption secret key. This means your security credential is transmitted externally every time a particular error is
triggered. During a bot attack, this error can fire repeatedly, repeatedly exposing the key.

---
Cookies Set Without Standard Security Protections

When the plugin sets tracking cookies in a visitor's browser, it does so without two standard security flags that protect against common browser-based attacks:

- HttpOnly — prevents browser scripts from reading the cookie (protects against cross-site scripting attacks)
- Secure — ensures the cookie is only sent over encrypted HTTPS connections

Both are considered baseline cookie hygiene and their absence is a straightforward fix.

---
A Race Condition Under Concurrent Load

The plugin uses a timestamp-based system to limit how often it contacts external services — for example, checking monitoring data no more than once every five
minutes. The check works by reading the last timestamp, comparing it to now, and updating it if enough time has passed.

Under high concurrent traffic, two requests can pass that check simultaneously before either has written the updated timestamp. The result: both fire the
external API call. Under a bot surge with many concurrent requests, this can mean bursts of redundant calls to ClickCease's servers, potentially triggering rate
limits on the very service meant to be protecting you.

---
Bottom Line

┌──────────────────────────────────────────┬────────────────────────────────────────────────────────────────┐
│ Issue │ Risk Under High Traffic │
├──────────────────────────────────────────┼────────────────────────────────────────────────────────────────┤
│ Multiple database writes per request │ Database contention, slower page loads site-wide │
├──────────────────────────────────────────┼────────────────────────────────────────────────────────────────┤
│ All settings autoloaded on every page │ Unnecessary overhead on every request, for every visitor │
├──────────────────────────────────────────┼────────────────────────────────────────────────────────────────┤
│ Credentials in plain text │ Full exposure if database is accessed by an unauthorized party │
├──────────────────────────────────────────┼────────────────────────────────────────────────────────────────┤
│ Secret key in error logs sent externally │ Repeated credential exposure during bot-triggered errors │
├──────────────────────────────────────────┼────────────────────────────────────────────────────────────────┤
│ Cookies without security flags │ Browser-level vulnerability for legitimate visitors │
├──────────────────────────────────────────┼────────────────────────────────────────────────────────────────┤
│ Race condition on API calls │ Redundant external calls precisely when bot traffic is highest │
└──────────────────────────────────────────┴────────────────────────────────────────────────────────────────┘

The fundamental design tension here is that this plugin's most demanding work — fraud detection — happens on the same database infrastructure it's putting under
strain. A bot attack is the worst time for your database to be fielding extra write traffic, which is exactly when this plugin generates it.