Does it matter if the CMS path /processwire/ is known?

[DrQuincy]

To keep the main site tree clean I have added a collection of JSON templates to /processwire/api/{reference}

However, it has occurred to me that this means I need to include that path in my JavaScript to make the API call.

Am I at any significant disadvantage if a hacker knows the CMS login path to be /processwire/? I know WP users change /wp-admin/ to something else but it is my understanding ProcessWire is much more secure. Does it really matter? The docs say there is dictionary attack protection built in via throttling.

Thanks.

[FireWire]

ProcessWire definitely shines in the security department and the login page does have throttling. I don't know what your threat model is but usually sites have to deal more with bots than individual bad actors, but that depends on the purpose/use for your site. I've built many PW sites over the years and not one has ever been compromised. In my opinion, your biggest threat as far as hackers go would be a person that came into possession of one of the users' login credentials or much more common automated attack scripts with other vectors like requests containing data that the code isn't prepared to handle, or MySQL injections in your forms.

Here are some additional thoughts on your login URL. If you don't want bad actors to know the login URL then it should be changed it to one that is practically unguessable like /clientname-admin-login or something easy to remember but hard to guess. Consider that your /processwire login URL is not unknowable because it's the default. Someone intent on getting to the login page or knowing what CMS you are using could analyze the markup and see that your images are being served from /site/assets/files/{page id} and any assets like JS may be served from the templates directory like /site/assets/templates/scripts- the file structure consistent across ProcessWire sites. When you load a page on a ProcessWire site, the server returns the request with the header "x-powered-by: ProcessWire CMS" unless you've disabled it and that will let someone look up what the default URL would be. Using /processwire in JS isn't really the issue.

All that aside, it's not automatically a disadvantage to have your login URL known. Most of the PW sites that are built probably keep /processwire. My take is that if you have the opportunity to change it and reduce the chance non-authorized people would see the login page to begin with, why not?

If this were my project I would change the login URL and create a dedicated /api page in the admin then use a hook to hide it in the page tree on render for non-superusers. It would keep the main site tree tidy as desired, allow for a clean semantic URL to work from, and not hard code in references to a part of the website that isn't content-related. If you want to take security against bots into consideration I would look into adding some bot blocking rules to your .htaccess file, I use 7G Firewall. Bot blocking prevents bot HTTP requests from requiring ProcessWire to boot up, analyze the URL, determine that it doesn't exist, and then serve the 404 page- this improves performance by reducing server load. Blocking bots also takes care of many other automated malicious requests as described above.

I kinda blew this open a bit, but I think your question about security being limited to hackers and the login page could benefit from a wider scope.

[DrQuincy]

Thanks a lot for such a detailed reply, it is most useful. ?

I always leave the login as /processwire but then they tend to be brochureware type sites so not exactly highly sensitive.

Quote

If this were my project I would change the login URL and create a dedicated /api page in the admin then use a hook to hide it in the page tree on render for non-superusers.

Yes, I think this is exactly what I will do. Like you say, it's easy to do so might as well.

[bernhard]

1 hour ago, DrQuincy said:

Quote

If this were my project I would change the login URL and create a dedicated /api page in the admin then use a hook to hide it in the page tree on render for non-superusers.

Yes, I think this is exactly what I will do. Like you say, it's easy to do so might as well.

As a simple addition to @FireWires great answer: Don't forget about the relatively new url hooks! https://processwire.com/blog/posts/pw-3.0.173/ You don't need a dedicated page then (which means that you also do not need to hide that page from the tree via hooks)

[DrQuincy]

Ah yes, good idea. I have used them already for some redirects.

[Clarity]

I think it is not good if admin's path is known to hacker, since they potentially can brute-force superusers' accounts by this URL and eventually hack someone's account, receiving the access to the Admin Panel. The hackers may know which CMS the site uses from the site https://whatcms.org/, and if they know a thing or two about ProcessWire, they will attack /processwire path first.

[flydev]

Just read the thread, and posting an idea to give future readers a solution I used on a setup in the past.

You can mitigate this "existing issue on every frameworks" by automating the whole things by writing a dedicated script which will change the admin url to a random generated string once called (could be a SHA hash, or whatever). Then you create a scheduled task that is calling this script with delay you want. 

When the script is called, it change the admin url to the new generated random string and make a call to a webhook, which on my case, was known by a self-made Telegram bot.

When I was in need to log-in, I asked the bot on Telegram the current admin url ?