For any measure of your own, think of two savings: First, the cost of doing nothing (high for a bank, down for a blog). measurement cost (development, maintenance, friction for legitimate users). Second, measures increase the cost of the attacker more than the cost to you and your users. Security is never absolute and always a compromise.

Limit automated / repeat access (bots / spam)

Forms are abused by flooding manually or automated. Any attack will be as close as possible to a legitimate request - the attacker's effort will depend on the reward.

• Use recaptcha etc.
• Block session or IP after x attempts 1
• Limit sending to x attempts / minute by IP 1 or to the whole site (which can harm legitimate users)
• Return a unique ID that was generated while displaying the form, valid for a single submission and for a limited time (Wikipedia does something like this: the attacker would have to reload the form, increasing the server load)
• Create a pause interval. If your form responds in 0.5s, a range of 5s is tolerable for users and reduces the number of submissions from 120 / s to 12 / s
• Need an email response
• Create a manual authentication ("Your registration needs to be authorized by the administrator").

Limit access of non-authenticated persons

Remember that HTTP is stateless , stateless. At first, each call you receive without prior history and must prove that you have already approved the issuer before:

• Proof that the user has been previously authenticated (it provides a cookie or a POST attribute of a session that exists on the server - third parties have to guess or steal the ID of an active session on the server)
• Prove that it visited another address before (HTTP_REFERER - easily forged)
• Prove that they know a certain secret (address / password / attribute in the special POST - can easily leak or be detected).

Limit access of all requests

• Ban IP sequences (from known offenders outside the company / client network, from a certain country - can be forged and disrupts legitimate users by accessing from an unusual place, such as travelers)
• Ban certain requests (eg never receive POST).

1 Everything related to IP can be fooled by using multiple IPs, VPNs or acquiring a new IP.

Effective is to check the "dns reverse lookup". In your hosting provider, configure or ask for the "dns reverse lookup" or "dns reverse" in Portuguese.

Then whenever you receive a request (POST, GET), check the "dns reverse lookup" for IP.

In PHP there are network functions like gethostbyname, gethostbyaddr and dns_get_record with which you can extract the data to aid in "authentication".

Note that the "dns reverse lookup" can also be circumvented, so do not trust 100% as an absolute solution. However, it is much safer than just checking HTTP_REFERER. HTTP_REFERER is easily manipulated, including CURL has the option to do so. But the reverse dns requires changing the configuration of the server that submits the data.

We can say that 99.999% of the bots can not change the reverse dns of the servers they use because, logistically, the bots target millions of servers and need to modify millions of times the reverse dns of the servers by which they execute their scripts. It is not feasible due to the high cost.

Example, if your site has the address www.seu.site, set the reverse dns to "www.seu.site". In a shared hosting server, it is not usually possible to customize, but you can ask the company that administers the server to at least configure the reverse dns so that a valid name is returned. Usually it gets something like "address.provider.hosting".