Think of it this way. If you expose your http provisioning service to the internet on a default FreePBX Distro install, then hackers only need to guess one of the provisioning file names in order to download it. Once they have a provisioning file for one of your phones, they have enough info to register their own client to your PBX, provided they also have access to the SIP Signalling port(s).
The next layer of security is adding Apache credentials. This is an option in System Admin pro, or you could configure it manually if you wish. With Apache credentials in place, the malicious user would not only have to guess a valid filename, they would have to guess the Apache user/password. Apache creds for provisioning is a somewhat recent development. Pretty much all popular current SIP phones support it, but legacy devices might not.
Next layer would be fail2ban configured to watch for Apache login failures, which is enabled by default on distro install. If properly configured, malicious hosts that fail the credential challenge get banned temporarily.
Final layer would be to block untrusted access to the provisioning services rendering all the above moot under normal circumstance. It is still wise to keep the above in place in the event that whatever method you’re using to block untrusted access fails and starts allowing access, which is exactly what happened in the exploit I wrote about here.
The above is talking about http, but all of it applies equally to https. https does literally nothing to prevent brute force attempts. What it does do encrypt the data between the pbx and the endpoint, making it more difficult for sophisticated attackers using a packet sniffer to discover Apache credentials or provisioning filenames. Good practice says don’t allow untrusted access. If you must, put as many roadblocks in place that you can, while still keeping the service usable to legit users.