Webmasters who use forms on their websites, e.g. contact or lead generation forms, should have a look at possible issues with
- Privacy and Security
- GET parameters
The <form> related hints reports highlight common problems related to form usage and help webmasters to prevent issues with security, privacy or GET parameters due to improper usage of forms.
Example: Audisto <form> Error Check with the <form> hint reports for the current crawl
Here is the list of all specific hints that are part of the <form> hints section and that can be identified with the help of the Audisto Crawler.
Table Of Content
<form> POST to HTTPS from HTTP
The form posts to an HTTPS URL, but resides on an HTTP URL. Use this report to identify all URLs within the website that contain forms, which are submitting data from an HTTP resource to an HTTPS resource, using the POST method.
http://example.com/form.html posts to https://example.com/form_submit.php
Example form markup:
<form action="https://example.com/form_submit.php" method="POST"> ... </form>
If a form action is defined to use the HTTPS protocol, this indicates that the entered data should be transferred using a secured channel. However, while the data would be sent encrypted, it is still a security issue. If the form data is sent from a URL that is not secured with SSL, then the form itself might be compromised by a man in the middle attack before the data gets posted.
You should deliver all forms encrypted, i.e. use HTTPS.
<form> Unsafe GET to HTTP from HTTPS
The form submits itself to an HTTP URL, but resides on an HTTPS URL. The form is using the GET method. Use this report to identify all URLs on the crawled website that contain forms which use the GET method to submit from HTTPS to HTTP.
Form included in https://example.com/
<form action="http://example.com/form-submit.php" method="GET"> ... </form>
In this situation, the data is transferred over an unsecured connection to the form action URL and the response will also be sent unsecured. Due to use of the GET method, the form input data will be part of the URL and openly visible to anyone able to access the URL. More than that, the GET method is cacheable, which allows the data to be cached on third party systems. This can be a severe security issue.
If you want to transfer your form input data safely, you may consider also delivering the form's target URL over HTTPS and switch from the GET method to the POST method.
<form> Unsafe POST to HTTP from HTTPS
The form submits itself to an HTTP URL, but resides on an HTTPS URL. The form is using the POST method. Use this report to identify all URLs on the crawled website that contain forms that use the POST method to submit from HTTPS to HTTP.
Form included in https://example.com/
<form action="http://example.com/form-submit.php" method="POST"> ... </form>
In this situation, the data is tranferred over an unsecured connection to the form action URL and the response is also be sent unsecured. This can be a severe security issue.
If you want to transfer your form input data safely, you can consider delivering the form's target URL over HTTPS too.
<form> method is GET
If a form using the GET method is found, the URL is flagged with this hint. This report shows all URLs on the crawled website that contain forms, which use the GET method.
<form method="GET" action="/submit.php"> ... </form>
If forms are submitted with the GET method, the form input data will become part of the URL that is requested. They are accessible to everyone who knows the exact URL, e.g. user, bots and search engines. This may lead to unexpected direct requests to these URLs.
If GET URLs are unexpectedly called out of context, it may result in waste of crawl budget and issues with the crawl rate. Furthermore, the GET method is defined as cacheable by default. Any URL generated by a form that uses the GET method may therefore be cached if not indicated otherwise, e.g. by status code or cache policy.
It is also noteworthy, that any form that uses the GET method along with freely definable input fields without restrictions, allows the generation of an unlimited number of unique URLs. If these get crawled and indexed, this might lead to issues with the crawl budget as well as with the indexing budget. This situation can be exploited for negative SEO.
If it is not your intention to generate URLs that can be accessed out of the form context, switch the form method to POST. Internal search forms often trigger this hint. You might consider blocking bots in the robots.txt from crawling the form action URL.
To avoid user experience problems after switching to the POST method, you might want to utilize the PRG-pattern. This avoids problems when reloading the document. If the PRG-pattern is not used, the browser will ask the user to resubmit the form, if the URL is reloaded.