DEV Community: Jonathan Pimperton

Is Your jQuery Version a Security Risk?

Jonathan Pimperton — Tue, 21 Apr 2026 10:00:26 +0000

Is Your jQuery Version a Security Risk?

WordPress, by default, includes a version of jQuery. This is great for developers because it means we don't have to worry about manually enqueueing it for most projects. However, there's a common pitfall: many themes and plugins bundle their own copy of jQuery. If this bundled version is outdated, it can introduce serious security vulnerabilities. Specifically, jQuery versions prior to 3.5.0 are known to have cross-site scripting (XSS) vulnerabilities, identified by CVE-2020-11022 and CVE-2020-11023. These issues could allow an attacker to inject malicious code into your site.

How to Check Your jQuery Version

The first step is to determine which version of jQuery your website is actually using. The easiest way to do this is by inspecting the page source.

View Page Source: In your web browser, right-click anywhere on your website's frontend and select "View Page Source" or "Inspect Element".
Search for jQuery: Once the source code is displayed, search for "jquery". You're looking for a <script> tag that loads the jQuery library. It will typically look something like this:
```
<script src="https://example.com/wp-content/plugins/some-plugin/assets/js/jquery-1.12.4.min.js"></script>
```
or
```
<script src="https://example.com/wp-content/themes/your-theme/js/jquery-3.3.1.min.js"></script>
```
The filename will clearly indicate the version. If you see a version number like 1.x.x, 2.x.x, or 3.0.0 through 3.4.x, you are likely vulnerable. WordPress itself ships with a secure version of jQuery, typically loaded from wp-includes/js/jquery/jquery.js or a similar path within the core WordPress files. If your site is only loading jQuery from this core path, you're probably fine. The problem arises when a theme or plugin loads its own version, often an older one.

Fixing Vulnerable jQuery Versions

Once you've identified an outdated jQuery version, you have a few practical options to address it.

1. Update Your Theme or Plugin

The most straightforward solution is to update the theme or plugin that's bundling the vulnerable jQuery version. Developers are aware of these vulnerabilities and have likely released updates that use a secure, modern version of jQuery or have removed the bundled copy altogether.

Action: Navigate to your WordPress dashboard, go to "Appearance" > "Themes" or "Plugins" > "Installed Plugins". Check for available updates for your active theme and any plugins. Apply them if they are available.

If updating is not an immediate option, or if the theme/plugin developer hasn't provided a fix, you'll need to take a more direct approach.

2. Dequeue the Vulnerable Script

WordPress provides functions to control how scripts are enqueued and dequeued. You can use wp_dequeue_script to remove the problematic, bundled jQuery from being loaded and ensure that the secure version provided by WordPress is used instead.

This is typically done in your theme's functions.php file or within a custom plugin. You need to know the handle that the vulnerable script was registered with. Often, themes and plugins will register their jQuery with a distinct handle. If they don't, it can be trickier, but usually, the script path itself can help you infer potential handles.

Here's an example of how you might dequeue a script. Let's assume the vulnerable script was registered with the handle 'old-jquery' and loaded from a path like /wp-content/themes/my-theme/js/jquery-1.10.2.min.js.

<?php
/**
 * Dequeue vulnerable jQuery version and ensure WordPress core version is used.
 */
function my_dequeue_vulnerable_jquery() {
    // Check if the script handle is registered.
    // The handle 'old-jquery' is an example; you'll need to find the actual handle.
    // If the handle is not known, you might need to inspect the source or plugin/theme code.
    if ( wp_script_is( 'old-jquery', 'registered' ) ) {
        wp_dequeue_script( 'old-jquery' );
        // Optionally, you can also de-register it to prevent it from being re-enqueued.
        // wp_deregister_script( 'old-jquery' );
    }

    // Ensure WordPress core jQuery is enqueued if it's not already.
    // This is generally handled automatically by WordPress, but can be explicit.
    // wp_enqueue_script( 'jquery' );
}
add_action( 'wp_enqueue_scripts', 'my_dequeue_vulnerable_jquery', 999 );
?>

Finding the Script Handle: This is the most challenging part of this method. If you can't find the handle by inspecting the theme/plugin's code directly, you might need to resort to some detective work. Sometimes the handle is close to the filename, or it's a common convention like jquery-custom or the plugin slug. If all else fails, you might have to look for the wp_enqueue_script() call within the theme or plugin's PHP files.

3. Migrate to Vanilla JavaScript

For new development or significant refactors, consider migrating away from jQuery entirely and using modern, vanilla JavaScript. Modern browsers have excellent support for features that jQuery abstracted, and the performance benefits can be significant. This is a more involved process but eliminates the dependency on jQuery versions and their associated vulnerabilities.

Action: Identify the jQuery-dependent functionality in your theme or plugin. Rewrite these functionalities using native JavaScript APIs. For example, replacing $(selector).hide() with document.querySelector(selector).style.display = 'none';.

By taking these steps, you can ensure your WordPress site is not compromised by outdated jQuery libraries, keeping your visitors and your data secure.

SiteVett checks this automatically as part of a free website QA scan with 60+ checks across security, SEO, content, performance, and more.

Using Sitevett, we scanned 100 agency websites. Here's what they miss.

Jonathan Pimperton — Fri, 10 Apr 2026 12:22:33 +0000

We ran a full automated QA scan across 100 web design agency websites -- the companies that build sites for a living. Every scan covered 69 rules: AI vision checks, Lighthouse performance audits, WCAG accessibility analysis, SEO validation, security header inspection, content quality, and more. Up to 80 pages per site.

27 sites were excluded because bot protection blocked the crawler, leaving 73 sites with valid results.

The average score was 69 out of 100. The highest score in the entire set was 84. No agency site scored above 84. More than half scored below 70.

See for yourself: here are the full reports for the top and bottom scorers.

Top 3:

Bottom 3:

The top 10 things agencies miss on their own websites

1. Accessibility statement (79% failed)

Nearly four in five agency sites have no accessibility statement. Some jurisdictions require one by law. Even where it's not legally mandated, it signals that the agency takes inclusive design seriously -- the kind of thing a prospective client notices.

2. Heading hierarchy (67% failed)

Two thirds of sites have pages with multiple H1 tags or broken heading structure. This confuses screen readers and dilutes the SEO signal that tells Google what the page is about. Most of these are template issues -- a logo or site title wrapped in an H1 alongside the page's actual heading.

3. Missing meta descriptions (51% failed)

Half the sites let Google generate their own search snippets. The result is usually the first sentence of body text, which rarely makes a compelling reason to click. A missing meta description is a missed opportunity on every single search result.

4. Color contrast (45% failed)

Nearly half of all sites have text that fails WCAG AA contrast requirements (4.5:1 ratio). The most common offender: white text on bright brand colours. Even well-known brand palettes like WhatsApp green (1.98:1) and YouTube red (3.19:1) fail the threshold. Popularity does not mean accessible.

5. Security headers (44% failed)

Missing CSP, X-Frame-Options, or Referrer-Policy headers. These are one-line server configurations that protect against clickjacking and XSS. HSTS adoption is better -- most sites have it. But the other three are often overlooked entirely.

6. Open Graph tags (37% failed)

More than a third of sites have no og:title, og:description, or og:image. When someone shares a link to the agency's site on LinkedIn or Slack, the preview shows a generic title and no image. For agencies that rely on referrals and word-of-mouth, this is leaving first impressions to chance.

7. Broken links (31% failed)

Nearly a third of sites have at least one broken link -- a page that returns a 404, a link to a defunct partner, or a portfolio piece that's been taken down. Broken links erode trust and hurt SEO. They accumulate silently over time.

8. Missing alt text (30% failed)

Three in ten sites have images without alt attributes. Alt text is the most basic accessibility requirement for images, and it's also how Google indexes image content. Portfolio-heavy agency sites are the worst offenders -- dozens of project screenshots with empty alt tags.

9. Canonical tags (27% failed)

Over a quarter of sites have pages without canonical tags, or with canonicals pointing to different URLs. Without them, search engines may treat URL variations (trailing slashes, query parameters, www vs non-www) as duplicate content.

10. Privacy policy link (25% failed)

One in four agency sites has no privacy policy link in the footer. Under GDPR and CCPA, this is a compliance gap. It's also one of the first things a privacy-conscious client will look for.

The numbers

Metric	Value
Sites scanned	100
Valid results (crawler not blocked)	73
Average score	69/100
Median score	69/100
Highest score	84/100
Scored 70-84	48%
Scored 50-69	52%
Below 50	0%
Total checks run	6,037

What else showed up

Beyond the top 10, some patterns stood out:

80% had grammar issues flagged -- mostly minor (possessives, compound modifiers), but present.
77% are missing Permissions-Policy headers -- a newer security header that controls which browser APIs third-party scripts can access.
71% of sites have images without width/height attributes, causing layout shift (poor Core Web Vitals CLS scores).
66% have meta title issues -- duplicates across pages, or titles that are too long/short for search results.
60% have generic anchor text like "click here" or "read more" on internal links.

Why this matters

These aren't amateur mistakes. These are professional web agencies -- companies that charge thousands to build and maintain websites. The issues they miss on their own sites are the same ones they miss on client sites.

Most of these problems are invisible in a browser. A missing canonical tag doesn't show an error. A broken heading hierarchy looks fine on screen. A 1.98:1 contrast ratio is readable to most people in good lighting. These are the gaps that manual review doesn't catch.

That's why we built SiteVett. One scan, 69 automated checks, a score out of 100, and a list of exactly what to fix. You can scan any site for free.

Data from SiteVett's 100-site agency benchmark, April 2026. All sites scanned with AI vision checks enabled, up to 80 pages per site. 27 sites excluded due to bot protection blocking the crawler.

SSL Certificate Expiry: The Silent Downtime Bomb

Jonathan Pimperton — Wed, 01 Apr 2026 14:58:48 +0000

SSL Certificate Expiry: The Silent Downtime Bomb

It’s a scenario every web developer and agency dreads. A client calls, frantic. Their website is down, or worse, showing a terrifying "Your connection is not private" warning. Visitors are gone. The cause, often, is a simple oversight: an expired SSL certificate. This isn't a catastrophic hack; it's a ticking time bomb with a predictable fuse.

Ignoring SSL certificate expiry is like leaving your front door unlocked. It might be fine for a while, but eventually, someone will notice, and the consequences can be severe. For businesses relying on their website for revenue or customer interaction, this downtime translates directly into lost money and damaged reputation. Browsers are increasingly strict about security, and an expired certificate triggers immediate user distrust.

Checking Your Certificate's Status

Knowing when your certificates expire is the first line of defense. Thankfully, there are several straightforward ways to check.

For a quick command-line check, openssl s_client is a handy tool. Run it against your domain and port 443 (the standard HTTPS port).

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com < /dev/null 2>/dev/null | openssl x509 -noout -dates

This command pipes the connection output to another openssl command that extracts just the "notBefore" and "notAfter" dates, showing you precisely when your certificate becomes valid and, crucially, when it expires.

Alternatively, you can use your browser's developer tools. Navigate to your website, open the DevTools (usually F12), go to the "Security" tab, and click on the certificate information. This will often show you the expiry date directly.

For a more automated approach, various online SSL checker tools exist. Websites like SSL Labs (ssllabs.com) provide comprehensive reports, including certificate expiry dates, alongside many other security metrics. These are excellent for quick, at-a-glance checks across multiple domains.

Automating Renewal with Let's Encrypt

The advent of free, automated certificates from Let's Encrypt has drastically reduced the manual burden of certificate management. Tools like certbot are designed to automate the entire process, including renewal.

If you're using certbot with Apache or Nginx, the renewal process is usually handled automatically by a cron job or systemd timer that runs the certbot renew command.

For example, a common certbot cron job might look like this:

0 0 * * * certbot renew --quiet

This runs the renewal check every day at midnight. certbot renew checks all installed certificates and renews any that are due for expiration within the next 30 days.

The Common Pitfall: Server Reloads

Here’s where many systems stumble, even with automated renewals. Let’s Encrypt and certbot are excellent at obtaining and renewing certificates. However, a certificate is only useful if the web server is aware of the new one. Many automated setups forget to tell the web server to reload its configuration to pick up the renewed certificate.

If certbot renews a certificate but your web server (like Nginx or Apache) hasn't been told to reload its SSL configuration, visitors will continue to see the old, soon-to-expire certificate until the server is manually restarted or reloaded.

certbot can often handle this for you if configured correctly. When you initially set up certbot with a web server plugin (e.g., certbot --nginx or certbot --apache), it typically adds a "deploy hook" or post-renewal hook. This hook is a command that runs after a certificate is successfully renewed. The common command for Nginx is:

systemctl reload nginx

And for Apache:

systemctl reload apache2

If you're not using a certbot plugin that handles this automatically, or if you're managing certificates manually, you must ensure your server configuration is reloaded after a certificate renewal. This is a critical step that is frequently missed, leading to the silent expiry bomb. Regularly testing your automated renewal process by forcing a renewal (e.g., certbot renew --force-renewal) and then checking your site is a good practice to ensure your hooks are working as expected.

SiteVett checks this automatically as part of a free website QA scan with 60+ checks across security, SEO, content, performance, and more.

Your .env File Might Be Public Right Now

Jonathan Pimperton — Wed, 01 Apr 2026 14:45:27 +0000

Your .env File Might Be Public Right Now

Many of us use .env files to manage environment-specific configurations, especially in WordPress development. These files often contain sensitive credentials for databases, API keys, and other critical services. The problem is, these files can, and often are, inadvertently exposed on production servers. This isn't just a theoretical risk; it's a common oversight that can have severe consequences.

The .env Exposure Vector

When you deploy a WordPress site, especially if you're not careful about what you include in your deployment package or what gets pushed to the webroot, your .env file can end up accessible to anyone with a browser. This is usually because it's accidentally copied into the public directory alongside your WordPress core files.

Checking for Exposure with curl

The simplest way to check if your .env file is exposed is to try fetching it directly using curl. If your web server is configured to serve it, you'll get its contents.

To check for .env:

curl -I yourdomain.com/.env

The -I flag tells curl to fetch only the headers. Look for a 200 OK status code. If you see that, you can then try fetching the content:

curl yourdomain.com/.env

If you get a response that looks like a .env file (e.g., DB_NAME=your_db_name), it's exposed.

Other Common Leaks

It's not just .env files. Developers also sometimes leave other sensitive files accessible:

.git/HEAD: If your .git directory is accidentally deployed to the webroot, fetching .git/HEAD might reveal the current branch you're on. This gives an attacker insight into your development workflow and potential vulnerabilities associated with older branches.
```
curl -I yourdomain.com/.git/HEAD
```
wp-config.php~: Many editors create backup files for configuration files. If these backups are not excluded from deployment and end up in the webroot, they can leak your database credentials.
```
curl -I yourdomain.com/wp-config.php~
```
debug.log: While not as critical for direct credential theft, leaving debug logs accessible can reveal internal workings, file paths, and potentially error messages that hint at other system vulnerabilities.
```
curl -I yourdomain.com/wp-content/debug.log
```

The Real Risk: Credential Theft and Source Code Exposure

The immediate and most significant risk is credential theft. A publicly accessible .env file, or a backup of wp-config.php, often contains your database username, password, database name, and sometimes API keys for third-party services. With these credentials, an attacker can:

Access and tamper with your database, potentially stealing user data, injecting malicious content, or deleting everything.
Gain access to your WordPress admin panel through brute-force attacks on stolen credentials.
Use your API keys to incur costs on your behalf or access sensitive information on integrated services.

Exposure of .git related files can indirectly aid attackers by revealing branch names, potentially pointing to unpatched vulnerabilities in older code.

Fixing the Exposure: Deny Rules and Webroot Exclusion

The fix involves two primary strategies: preventing direct web access and ensuring sensitive files are never in the webroot.

1. Server Configuration Deny Rules

The most robust solution is to configure your web server to explicitly deny access to these files.

For Apache (.htaccess):

Add these lines to your .htaccess file in the webroot:

<FilesMatch "^\.(env|\.git/HEAD|wp-config\.php~|debug\.log)$">
    Order allow,deny
    Deny from all
</FilesMatch>

For Nginx:

Add these rules to your server block configuration for your site:

location ~* ^/(.env|\.git/HEAD|wp-config\.php~|debug\.log)$ {
    deny all;
}

If you use a subdirectory for logs, like wp-content/debug.log, you'll need to adjust the Nginx location accordingly:

location ~* ^/wp-content/(debug\.log)$ {
    deny all;
}

These rules tell the web server that if any request matches these filenames, it should immediately return a forbidden error instead of serving the file's content.

2. Remove Backups and Sensitive Files from Webroot

Beyond deny rules, the best practice is to ensure these files are never copied into your webroot in the first place.

.env files: These should always reside in the directory above your webroot. For example, if your webroot is /var/www/html/yourdomain.com/public_html, your .env file should be at /var/www/html/yourdomain.com/.env. Your application, typically via a framework or WordPress plugin, will then read this file.
.git directories: When deploying, ensure you're not deploying the entire .git directory. Use deployment tools that only copy necessary application files. Git hooks or build scripts can be used to clean up .git artifacts before deployment.
Editor backups: Configure your text editor or IDE to not save backup files in the project directory, or ensure they are excluded from your deployment process.
Debug logs: Configure WordPress to log debug information to a file outside the webroot, if possible, or at least ensure the log file itself is protected by server configuration.

By implementing these checks and preventative measures, you significantly reduce the attack surface for your WordPress sites and protect sensitive credentials and code.

SiteVett checks this automatically as part of a free website QA scan with 60+ checks across security, SEO, content, performance, and more.

Is Your Site Redirecting HTTP to HTTPS? Here's How to Check

Jonathan Pimperton — Wed, 01 Apr 2026 14:03:43 +0000

Is Your Site Redirecting HTTP to HTTPS? Here's How to Check

You've installed an SSL certificate, great. But is traffic automatically being sent to the secure HTTPS version of your site? A common oversight is having the certificate in place but failing to enforce the redirect from HTTP. This leaves visitors hitting the insecure version of your domain, which is bad for SEO, user trust, and data security. Let's cover how to check this and fix it.

Checking with `curl`

The command-line tool curl is your friend here. It allows us to make raw HTTP requests and inspect the responses. We're looking for a 301 Moved Permanently or 302 Found redirect status code.

To test the HTTP to HTTPS redirect, open your terminal and run:

curl -I http://yourdomain.com

Replace yourdomain.com with your actual domain. The -I flag tells curl to fetch only the headers, not the body of the response.

In the output, you'll want to see something like this:

HTTP/1.1 301 Moved Permanently
Location: https://yourdomain.com/
... other headers ...

If you see HTTP/1.1 200 OK, it means your site is responding to the HTTP request directly without a redirect.

Also, test both www and non-www versions of your domain, for example:

curl -I http://www.yourdomain.com

Implementing Redirects

The method for setting up the redirect depends on your server environment or hosting provider.

Apache `.htaccess`

For most shared hosting or VPS setups running Apache, you'll add rules to your .htaccess file, typically located in the public root directory of your website.

To redirect all HTTP traffic to HTTPS, add the following lines to your .htaccess file:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

This configuration checks if the request is not already using HTTPS. If it's not, it issues a 301 redirect to the same host and URI, but with the https:// protocol. The [L] flag ensures this is the last rule processed.

Nginx

If you're using Nginx, you'll modify your server block configuration. Locate the server block that handles your HTTP traffic (usually port 80) and add a redirect.

Here's a common Nginx configuration for redirecting HTTP to HTTPS:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name yourdomain.com www.yourdomain.com;
    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem; # Example path
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem; # Example path
    # ... other SSL configuration and your site's root directives ...
}

The first server block listens on port 80, matches your domain names, and redirects all requests to the HTTPS version using a 301 status code.

Cloudflare

If you use Cloudflare, it simplifies this process significantly. Cloudflare has a dedicated SSL/TLS setting called "Always Use HTTPS".

Log in to your Cloudflare dashboard.
Select your website.
Navigate to the "SSL/TLS" section.
Under "Edge Certificates," find "Always Use HTTPS" and toggle it to "On."

This setting tells Cloudflare to automatically issue 301 redirects for any requests that come in over HTTP to the equivalent HTTPS URL.

Common Pitfalls

Redirect Loops: This is a common headache. It happens when multiple redirects are configured and they send traffic back and forth. For instance, if your server is configured to redirect HTTP to HTTPS, and then Cloudflare is also set to "Always Use HTTPS," you might encounter a loop. Ensure only one mechanism is actively forcing the HTTPS redirect. Check your .htaccess, Nginx config, and Cloudflare settings carefully. If you use a WordPress plugin for SSL, make sure it's not conflicting with server-level redirects.

Mixed www and Non-www: Decide whether you want your primary domain to be www.yourdomain.com or yourdomain.com and stick to it. All your redirects should enforce this canonical version. For example, if your preferred version is www.yourdomain.com, your HTTP to HTTPS redirect should point to https://www.yourdomain.com, and you should also have a separate redirect for https://yourdomain.com to https://www.yourdomain.com (and vice versa if yourdomain.com is preferred).

Your .htaccess file can handle this by adding rules for the non-preferred version:

# Redirect non-www to www
RewriteEngine On
RewriteCond %{HTTP_HOST} ^yourdomain.com$ [NC]
RewriteRule ^(.*)$ http://www.yourdomain.com/$1 [L,R=301]

# Then redirect HTTP to HTTPS for both
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

The order here is important. You generally want to resolve the www preference first, then enforce HTTPS.

SiteVett can automatically check this for you as part of a free website QA scan.

DEV Community: Jonathan Pimperton

Is Your jQuery Version a Security Risk?

Is Your jQuery Version a Security Risk?

How to Check Your jQuery Version

Fixing Vulnerable jQuery Versions

1. Update Your Theme or Plugin

2. Dequeue the Vulnerable Script

3. Migrate to Vanilla JavaScript

Using Sitevett, we scanned 100 agency websites. Here's what they miss.

The top 10 things agencies miss on their own websites

1. Accessibility statement (79% failed)

2. Heading hierarchy (67% failed)

3. Missing meta descriptions (51% failed)

4. Color contrast (45% failed)

5. Security headers (44% failed)

6. Open Graph tags (37% failed)

7. Broken links (31% failed)

8. Missing alt text (30% failed)

9. Canonical tags (27% failed)

10. Privacy policy link (25% failed)

The numbers

What else showed up

Why this matters

SSL Certificate Expiry: The Silent Downtime Bomb

SSL Certificate Expiry: The Silent Downtime Bomb

Checking Your Certificate's Status

Automating Renewal with Let's Encrypt

The Common Pitfall: Server Reloads

Your .env File Might Be Public Right Now

The .env Exposure Vector

Checking for Exposure with curl

Other Common Leaks

The Real Risk: Credential Theft and Source Code Exposure

Fixing the Exposure: Deny Rules and Webroot Exclusion

1. Server Configuration Deny Rules

2. Remove Backups and Sensitive Files from Webroot

Is Your Site Redirecting HTTP to HTTPS? Here's How to Check

Is Your Site Redirecting HTTP to HTTPS? Here's How to Check

Checking with curl

Implementing Redirects

Apache .htaccess

Nginx

Cloudflare

Common Pitfalls

Checking with `curl`

Apache `.htaccess`