> we try our best to hide this fact

Can't really hide wordpress because any time there's a new vulnerability, scrapers spam every site on the internet attempting to use it it anyway, regardless of what tech they're built on

I'm curious what efforts you've made to "hide" WordPress. Can you share any of your techniques? I assume it's stuff like:

- Rename paths to eliminate "wp-" prefixes and recognizable folder structure (wp-content, wp-include, etc)

- Remove or rename any common plugins that inject recognizable WP-specific code into the page

- Rewrite requests to bare paths instead of e.g. index.php

I assume you'd also try to do as much handling as possible at the Apache/NGINX layer instead of letting requests hit the WP application.

Seems like a HUGE amount of effort, and I'm probably not even getting everything. Is there a more efficient way of securing/locking-down a WP site?

For cyph.com/blog, we have a WordPress instance accessible only by SSH tunnel, and what gets deployed publicly is a static site generated using a plugin called Simply Static (with a little bit of additional processing).

How long does it usually take for a small site to be generated using Simply Static? I tried it once before, and wasn't very impressed by the performance (I don't think it's a problem with the plugin, but maybe PHP itself).

Simply Static itself takes about a minute, but it's actually a decent amount longer because we have to simulate a browser and run retry logic to handle failures. All in all, with post-processing included, the static blog generation is the single longest part of our deployment process.

Ultimately it isn't a huge deal for us though, since it runs concurrently with other build/deployment steps that in total (sequentially) take a similar amount of time.

I've run it on a simple bog-standard out-of-the-box Wordpress install with no obfuscation just now and it said "No apps found". Not sure what the issue is.

One thought I had was perhaps it uses some cached batch parser and shows "No apps found" for all sites on first-run until it finishes analysing in the background? It doesn't seem to work at all on a few very obvious but small/obscure CMS sites but works fine on all well-known high-traffic sites.

It could be something as simple as the class names of elements on the page. WP has some defaults that are recognizable.

Also, most WP pages will be loading scripts from from the wp-includes directory. There are probably others I'm overlooking, and some WP plugins probably also drop recognizable script tags into your pages.

Since this is the first tool that has detected it, it's very possible you've already covered all of the things I mentioned.

Yes, `wp-contents`, `wp-includes` and basically anything else prefixed with `wp-` is a very clear signed that WordPress is behind the site.

Well, you'll certainly be interested in wpscan.

The WP REST API is a new way to detect if a site is running WordPress. If you hit the homepage of a WordPress site it will return a link header with a location to the REST API. They can also just hit /wp-json/, or /xmlrpc.php, or many other files that WordPress requires. Like looking for assets served from wp-content, or wp-includes.

You really shouldn't be relying on security by obscurity to prevent attacks to your websites. If you check your access logs you'll see countless attacks that are unconditional, they'll just try the attacks without any kind of sanity checking.

I don't know what they're using, but Wappalizer uses regular expressions over the HTML. You can intentionally mislead the scanner without much effort.

Could it be as simple as checking if certain .php files respond to web requests?