DEV Community: Jonathan Pimperton

Open Directory Listings: The WordPress Security Hole You Forgot

Jonathan Pimperton — Tue, 12 May 2026 10:00:35 +0000

Open Directory Listings: The WordPress Security Hole You Forgot

Many web developers and WordPress agencies focus heavily on application-level security: keeping WordPress core updated, using reputable plugins, and implementing strong user authentication. These are all critical, of course. However, there's a more fundamental web server configuration issue that often gets overlooked and can inadvertently expose sensitive information: open directory listings.

Most of us know that Apache and Nginx serve files. When a request comes in for a directory (like /wp-content/uploads/), and there's no index file (like index.html or index.php) present, the web server has a choice: either deny access or display a list of the files and subdirectories within that directory. This latter behavior, known as "directory indexing" or "autoindexing," can be a significant security vulnerability.

The Problem: Revealing Your File Structure

Imagine a typical WordPress installation. You have your core files, your theme files, and your plugin files. Crucially, the /wp-content/uploads/ directory houses all the media that users upload to your site. If directory indexing is enabled on your server, a malicious actor or even a curious competitor can simply navigate to this URL in their browser:

https://your-wordpress-site.com/wp-content/uploads/

If directory listing is on, they'll see a nicely formatted list of all the files and folders within your uploads directory. This might seem innocuous at first glance. You uploaded some images, maybe a PDF or two. But consider what else might end up in there, intentionally or unintentionally:

Sensitive documents: If a client uploaded a document containing personally identifiable information (PII) or proprietary business data and it landed in a publicly browsable directory, that data is now exposed.
Backup files: Developers sometimes create temporary or even accidental backups of configuration files or other sensitive data and upload them without realizing the implications.
Exploitable code or configurations: While less common, improperly secured files containing custom code or server configurations could be revealed.
Detailed file structure: Even if no directly sensitive files are present, the listing provides a clear map of your site's internal file structure. This information can be invaluable to an attacker planning further exploits. They can see exactly where themes are stored, where plugins reside, and other organizational details they can use to tailor their attacks.

Testing for Open Directory Listings

You can easily test your own WordPress sites. Open your web browser and navigate to your primary upload directory:

https://your-wordpress-site.com/wp-content/uploads/

If you see a list of your uploaded files and folders, directory indexing is enabled. Try navigating into a subfolder as well, for example:

https://your-wordpress-site.com/wp-content/uploads/2023/10/

If you can see the contents of that month's upload folder, you have a problem.

The Fix: Disabling Directory Indexing

Fortunately, disabling directory indexing is straightforward and is a fundamental security best practice for any web server. The method depends on whether you're using Apache or Nginx.

Apache: Using `.htaccess`

For Apache servers, the most common way to manage this is through a .htaccess file located in the relevant directory. Place the following directive within a .htaccess file in your /wp-content/uploads/ directory:

Options -Indexes

If you want to apply this globally to your entire WordPress installation (which is often recommended for added security), you can place this directive in the .htaccess file in your WordPress root directory.

Important: If you already have a .htaccess file in that directory, add Options -Indexes on a new line. Ensure there are no conflicting Options +Indexes directives.

Nginx: Server Configuration

For Nginx, directory indexing is controlled within the server block configuration. You'll need to edit your Nginx site configuration file (often found in /etc/nginx/sites-available/ or similar). Within the location block that serves your WordPress files, you'll want to ensure autoindex is turned off.

Here’s a typical example of a location block for serving static files where you'd ensure autoindex is explicitly off, or simply not present (as it defaults to off):

location /wp-content/uploads/ {
    # Other directives like try_files, expires etc. can go here.
    autoindex off; # Explicitly turn it off, though usually off by default.
}

If you are serving your entire WordPress site from a single location / {} block, you might want to be more specific or ensure the default is respected. A common pattern for WordPress with Nginx involves a main location block and then specific ones for static assets. If you're not explicitly enabling autoindex, you are generally safe. However, for clarity and to prevent accidental enablement, you can add autoindex off; to any relevant location blocks.

After making changes to your Nginx configuration, remember to test the configuration and reload Nginx:

sudo nginx -t
sudo systemctl reload nginx

Beyond Uploads

While /wp-content/uploads/ is the most common and often the most impactful place for this vulnerability, consider if other directories might contain sensitive information that could be accidentally exposed if directory indexing were enabled. For most standard WordPress sites, disabling it for /wp-content/uploads/ is the priority.

This might seem like a minor configuration detail, but in the realm of web security, even small oversights can have significant consequences. Regularly auditing your web server configurations for issues like open directory listings is a vital part of maintaining a secure WordPress environment for your clients.

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

4 Security Headers Every Website Should Have

Jonathan Pimperton — Tue, 28 Apr 2026 10:00:44 +0000

4 Security Headers Every Website Should Have

As web developers and agencies, we're constantly building and optimizing. While performance and features get a lot of attention, security can sometimes take a backseat. This is a mistake. Implementing a few key HTTP security headers is a relatively low-effort, high-reward way to significantly improve your site's defense against common attacks.

These headers are instructions sent from your web server to the user's browser. The browser then enforces these rules, making it harder for attackers to exploit vulnerabilities. Let's cover four essential ones.

HSTS (HTTP Strict Transport Security)

HSTS tells the browser to only connect to your website using HTTPS, even if the user types in http://yourdomain.com or clicks an old http link. This prevents "man-in-the-middle" attacks where an attacker intercepts an HTTP connection to steal or modify data.

The header looks like this: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.

max-age: How long the browser should remember to enforce HTTPS (here, one year).
includeSubDomains: Applies the rule to all subdomains.
preload: This is optional but powerful. It allows you to submit your site to a browser-maintained list, so even the first visit defaults to HTTPS.

Common Mistake: Trying to implement HSTS before you are absolutely certain your entire site, including all subdomains and assets, is correctly served over HTTPS. If your HTTPS setup has issues, HSTS will prevent users from accessing your site entirely. Test thoroughly.

Checking with curl:

curl -I https://yourdomain.com

Look for the Strict-Transport-Security header in the output.

Configuration Examples:

Apache: Add to your .htaccess file or virtual host configuration. Ensure mod_headers is enabled.

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>

Nginx: Add to your server block.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Cloudflare Workers:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const response = await fetch(request);
  response.headers.set('Strict-Transport-Security', 'max-age=31536000; includeSubDomains; preload');
  return response;
}

Content-Security-Policy (CSP)

CSP is a powerful header that helps mitigate cross-site scripting (XSS) and other code injection attacks. It allows you to specify which sources of content (scripts, styles, images, etc.) the browser is allowed to load for your page. It's like a whitelist for your website's resources.

A basic CSP might look like: Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; object-src 'none'; base-uri 'self'.

default-src 'self': By default, only allow content from your own domain.
script-src 'self' https://trusted.cdn.com: Specifically allow scripts from your domain and a trusted CDN.
object-src 'none': Prevent plugins like Flash or Java from being loaded.
base-uri 'self': Restrict the URLs that can be used in a page's <base> tag.

CSP can get complex quickly, and it's best to start with a restrictive policy and then loosen it as needed based on your site's requirements. Use report-uri or report-to directives to log violations before going fully enforced.

Checking with curl:

curl -I https://yourdomain.com

Look for the Content-Security-Policy header.

Configuration Examples:

Apache:

<IfModule mod_headers.c>
    Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; object-src 'none';"
</IfModule>

Note: 'unsafe-inline' for scripts is often necessary for WordPress themes and plugins. Aim to remove it over time by moving inline scripts to external files.

Nginx:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; object-src 'none';" always;

Cloudflare Workers:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const response = await fetch(request);
  response.headers.set('Content-Security-Policy', "default-src 'self'; script-src 'self' 'unsafe-inline'; object-src 'none';");
  return response;
}

X-Frame-Options

This header controls whether your site can be embedded within an <iframe>, <frame>, <object>, or <applet>. This is crucial for preventing "clickjacking" attacks, where an attacker tricks a user into clicking on something different from what they perceive.

Common values:

DENY: The page cannot be displayed in a frame, regardless of the site attempting to do so.
SAMEORIGIN: The page can only be displayed in a frame on the same origin as the page itself.
ALLOW-FROM uri: The page can only be displayed in a frame on the specified origin. (This is deprecated and less reliable).

Checking with curl:

curl -I https://yourdomain.com

Look for the X-Frame-Options header.

Configuration Examples:

Apache:

<IfModule mod_headers.c>
    Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>

Nginx:

add_header X-Frame-Options "SAMEORIGIN" always;

Cloudflare Workers:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const response = await fetch(request);
  response.headers.set('X-Frame-Options', 'SAMEORIGIN');
  return response;
}

Referrer-Policy

The Referrer-Policy header controls how much referrer information (the URL of the page that linked to the current page) is sent with requests. Sensitive information can be leaked through the referrer header, especially when navigating from secure to non-secure pages, or between different sites.

Common values:

no-referrer: No referrer information is sent.
no-referrer-when-downgrade: Referrer is sent only when the target scheme is more secure than the current one (e.g. HTTP to HTTPS).
origin-when-cross-origin: Only send the origin (scheme, host, port) when the destination is cross-origin.
strict-origin-when-cross-origin: Send the origin only when the destination is cross-origin, and send the full URL only when it's same-origin.
same-origin: Referrer is sent only when the destination is same-origin.

For most sites, strict-origin-when-cross-origin is a good balance between privacy and analytics functionality.

Checking with curl:

curl -I https://yourdomain.com

Look for the Referrer-Policy header.

Configuration Examples:

Apache:

<IfModule mod_headers.c>
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Nginx:

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Cloudflare Workers:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const response = await fetch(request);
  response.headers.set('Referrer-Policy', 'strict-origin-when-cross-origin');
  return response;
}

By implementing these four headers, you're taking significant steps to secure your websites and protect your users. Regularly test your headers using tools like curl or online security scanners to ensure they are configured correctly and consistently.

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

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

Open Directory Listings: The WordPress Security Hole You Forgot

Open Directory Listings: The WordPress Security Hole You Forgot

The Problem: Revealing Your File Structure

Testing for Open Directory Listings

The Fix: Disabling Directory Indexing

Apache: Using .htaccess

Nginx: Server Configuration

Beyond Uploads

4 Security Headers Every Website Should Have

4 Security Headers Every Website Should Have

HSTS (HTTP Strict Transport Security)

Content-Security-Policy (CSP)

X-Frame-Options

Referrer-Policy

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

Apache: Using `.htaccess`

Checking with `curl`

Apache `.htaccess`