HTML - Will browsers autofill hidden fields? - html

My site suffers from a lot of spam bots. If I have the login form:
<input name="username" type="hidden" />
<input name="password" type="hidden" />
<input name="hidden_1" type="text" />
<input name="hidden_2" type="password" />
So the user actually see's the 'hidden' prefix fields, and the username/password named fields are actually the hidden ones. If the username or password field is submitted with values, we know bot filled them out and can ban them.
My question is, do browsers auto fill hidden fields? Is this quite a good technique? I know this isn't going to stop all bots that are semi intelligent, but if this even blocks 1 bot, without affecting any genuine users it's worth doing.

I think that not all bots just search for "username" and "password" names, but also type="password". So this might not avoid bot access at all.
You can use a capture like ReCAPTCHA. It is free and easy to use. Additionally you can create a banlist and show a 404 to bots via htaccess.

This article might help you:
http://www.smashingmagazine.com/2011/03/04/in-search-of-the-perfect-captcha/
Your method is actually fairly decent, but you may still suffer from some spam, especially if forms are manually filled out

Related

Chrome/Firefox autocomplete=new-password not working

I'm trying to add autocomplete=new-password to some user-editing forms, but it fails to follow the correct behavior in Chrome 79 and Firefox 71. It's supposed to be supported in both browsers.
What's wrong here?
I created two very simple examples to remove any external interference to the issue. They can be served from any HTTP server (e.g. php -S localhost:8999). The first page triggers the "save login" feature, but the second should NOT use that info to autocomplete the password - yet, it does.
<!-- login.htm -->
<html>
<head></head>
<body>
<form action="edit.htm" method="post">
<label>Login <input type="text" name="login" /></label></br>
<label>Password <input type="password" name="pwd" /></label><br />
<input type="submit">
</form>
</body>
</html>
<head></head>
<body>
<form>
<label>Login <input type="text" name="login" /></label></br>
<label>New Password <input type="password" name="pwd" autocomplete="new-password" /></label><br />
<input type="submit">
</form>
</body>
</html>
This is not exactly a dup from "how to use autocomplete=new-password" as the behavior seems to have changed or is ill-documented.
This seems to be an issue/advantage that browsers force pages to behave this way, and absolutely this is not fixed when setting autocomplete="new-password" or even if you set the value to off. but there seems to be a workaround to fix this issue caused accidentally by the browser.
- HTML way:
You can fix this by adding hidden fields at the top of your form to distract the browser
<!-- fake fields are a workaround for chrome/opera autofill getting the wrong fields -->
<input id="username" style="display:none" type="text" name="fakeusernameremembered">
<input id="password" style="display:none" type="password" name="fakepasswordremembered">
- JS way:
you can just set the password input to readonly the change its state
<html>
<head></head>
<body>
<form>
<label>Login <input type="text" name="login"/></label></br>
<label>New Password <input type="password" id="password" name="pwd" readonly autocomplete="new-password"/></label><br/>
<input type="submit">
</form>
<script>
document.getElementById('password').onfocus = function() {
document.getElementById('password').removeAttribute('readonly');
};
</script>
</html>
As you didn't reply to my comments I suppose that my assumption was correct. So I'll post the comments as the answer:
I don't have Chrome 79 and Firefox 71. I've tested it on Chrome 85 and FF 80 on Ubuntu.
It works as intended.
I assume that by
should NOT use that info to autocomplete the password - yet, it does.
you mean that:
When the password field gets focus browsers show a drop-down list with an option to fill in the field with previously stored password.
This looks to you as
[browsers] should NOT use that info to autocomplete the password.
[...] the behavior seems to have changed or is ill-documented.
But actually this is exactly the intended behavior.
From this (the previous paragraph on the same page you've linked) you can see the reason:
Even without a master password, in-browser password management is generally seen as a net gain for security. Since users do not have to remember passwords that the browser stores for them, they are able to choose stronger passwords than they would otherwise.
For this reason, many modern browsers do not support autocomplete="off" for login fields
If a site sets autocomplete="off" for username and password fields, then the browser still offers to remember this login, and if the user agrees, the browser will autofill those fields the next time the user visits the page.
Of course, it's about autocomplete="off" not about autocomplete="new-password"
Let's read further
If you are defining a user management page where a user can specify a new password for another person, and therefore you want to prevent autofilling of password fields, you can use autocomplete="new-password".
This is a hint, which browsers are not required to comply with. However modern browsers have stopped autofilling <input> elements with autocomplete="new-password" for this very reason.
From this:
autofilling is not the same thing as suggestions
browser CAN, but not SHOULD prevent autofilling
autocomplete="new-password" prevents autofilling not suggestions
So when you set autocomplete="new-password" browsers stop filling these fields but continue to show drop-downs with suggestions.
There is nothing about autocomplete="new-password" stopping suggestions, and there is a clear reason why suggestions are always available.
Yes, maybe the wording is a little bit confusing, but follows the behavior to the word.
About the history and use-cases behind this feature you can read here
And now about use-cases... why do you need this?
If several users have access to the computer, disabling suggestions won't stop them from logging in to a site as a different user. They can see passwords in the settings and use them. To prevent this, users must have different accounts on the computer.
If you don't want them to use old password in place of a new-password, then, yes, it will complicate things a little (which is actually bad - when things are complicated users tend to use poor passwords), but won't stop them from remembering the old password or, again, from getting it from the settings. For that you need to check if the password is really new in your code.
If you want to prevent suggestions anyway, then you can use hacks from #Moayad.AlMoghrabi's answer (I haven't tested them, but I believe he did). But without knowing your use case, I would strongly recommend against it. It breaks user experience and does not boost security. On the contrary, lessens it.
I know what your talking about, and in your case you should leave it. Security is a major issue, obviously, and the answers above are absolutely correct. There are work-arounds though, like using read-only which has been mentioned, I would try to achieve your goal using read-only, however; read-only does not always give disired results. A less favorable, and I feel like someone is going to lecture me hard for answering with this, but I feel as a developer, you need all the information, what you do with that information is your decision.
PSEUDO ELEMENTS
Googles chrome and Safari, imho, are the most annoying when it comes to auto-fill. To get around this, one option is to create HTML pseudo elements for the pwd and login inputs. Hide them using CSS display property set to none. Since google will only auto-fill one password-input element, and one username text-input element, this work around tricks Google into auto-filling elements that are not displayed.
The Problem With This Method
The problem with this method is that you need to make sure that you validate the data on the backend, and even more so, you need to make-sure your using the right elements to pull data from for your database. The worst problem is that as things update this work-around will guaranteed, at some-point, either stop working and the elements will one-day show without you knowing, making not developers using your site very confused, or confuse the browser in ways we cannot predict because the changes have not come. Its somthing you always have to be aware of. I use to use this method alot, but I stopped because people who know a lot more than I do, really did not like me doing it.
End Note:
Every browser is programed to present forms differently. Some browsers, especially mobile versions and safari actually change the physical look of your elements, which IMO is uncalled for. At the same time though they do this to try and deliver web standards to boost security and make things easier to use for people like my non tech-savvy 85 year-old Grandma. As noted, browser do things differently, and people can choose different browsers, selecting the one they want. Auto-fill is part of the experience that users get from a browser, and is a major deciding factor on which browser people choose. If you use work around, like the one I explained you change that browser experience, and give the user what you want, but it might not be what they want.
If you do decide to use, or at-least try this method, please let me know how it goes, its a pretty easy hack/work-around, and I have got pretty good at tricking browsers and can help you if my example doesn't work for you. Let me know what backend your using and browsers your experimenting with and I will get you working code, but first think about what you really want. Sometimes we have to settle, especially if it is in the best interest of the clients experience using the sites/apps we build, or to improve the security of, not just the client but, our servers and our self.
body{
width: 100vw;
padding: 0;
margin: 0;
background-color: #ddb;
overflow-x: hidden;
}
#login-psuedo{
display: none;
}
#pwd-psuedo{
display: none;
}
<html>
<head>
<style></style>
</head>
<body>
<form>
<input id="login-psuedo" type="text" name="login-psuedo"/>
<input id="pwd-psuedo" type="password" name="pwd-psuedo" autocomplete="new-password"/>
<br />
<label>Login <input type="text" name="login"/></label></br>
<label>New Password <input type="password" name="pwd" autocomplete="new-password"/></label>
<br>
<br>
<input type="submit" value="Submit">
</form>
</html>
I know quite an old question.
But adding autocomplete="off" in the form tag might help (I know not in all cases - as some fields might require autocomplete fills - Specially when you are testing)
works for firefox now* (*98.0.2 (64-bit))

What are Apple's autofill field names?

Now that Mavericks is out, and it can use autofill to handle credit card info, are there specific field names they look for?
Well I'm not sure exactly about how Mavericks handles it but in chrome you can accomplish autofill in a way like this:
<form method="post" autocomplete="on">
<input name="cc-name" autocomplete="cc-name" type="text" placeholder="Full Name" required />
<input name="cc-number" autocomplete="cc-number" type="text" placeholder="Credit Card Number" required />
<input name="cc-exp" autocomplete="cc-exp" type="text" placeholder="Expire Date" required />
<input type="submit" name="submit" value="Send my personal info to this person.." />
</form>
If safari works how chrome does it might have a regex scanner that looks for familiar terms and fills it in to the best of it's ability. It's very difficult to find any full details on how properly write an autocomplete form. The best bet is try it out and see what works then update your post with your results.
From my research it seems that for an autocomplete form to be filled with credit card info the web page MUST be under a secure domain ( https:// )
This is a list of all the autofill values that might work http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#autofill-field
Good luck! and don't abuse it.. That being said, not too many people will actually have their credit card set up for autofill for security reasons. I personally wouldn't for the risk of someone abusing the autofill feature and stealing my information with malicious JavaScript.

Question about POST method security

Let say I have a post from like this:
<form action="myApp/form_action.asp" method="post">
First name: <input type="text" name="fname" /><br />
Last name: <input type="text" name="lname" /><br />
<input type="submit" value="Submit" />
</form>
So, let say there is a really bad buy who want to do something in my application. For example, my form_action.asp not only accept param "fname", "lname", but also "gender", can he/she make a request on their own , like this....
<form action="http://www.myDomain.com/myApp/form_action.asp" method="post">
First name: <input type="text" name="fname" /><br />
Last name: <input type="text" name="lname" /><br />
Gender: <input type="text" name="gender" /><br />
<input type="submit" value="Submit" />
</form>
****Updates:****
I don't want the user submit the gender, because I don't want to modify his/her gender after he/she assigned.
If he/she can submit this query, it there any way to avoid him/her to do so? thank you.
You're thinking about this the wrong way. Forget about HTML forms. They're not what your server handles. It handles HTTP requests.
And (pretty obviously) people can send you HTTP requests that contain whatever they want. Not just additional fields, but also fields with values that the form would not allow, or fields with names that are 5000 characters long and/or values that are that long.
So what you absolutely must do is define what constitutes valid input and reject input that isn't. In your case, it's pretty simple: if the form is not supposed to contain a "gender" field, then have the server ignore such a field, or abort with an error if it's present.
Usually you don't have to do anything to ignore fields. But you definitely have to write your app in such a way that it does not accept field values that are not valid.
You cannot avoid this. Inputs coming from the clientside are NEVER secure and can ALWAYS be tampered with.
You'll have to implement your checks serverside, in the ASP file itself.
The reason you can't avoid it is that he doesn't need to make his own copy and submit it from another domain. He can easily modify your site live with javascript (e.g.: firebug) and send the fake request identical to a valid one.
If your form action file i.e. form_action.asp doesn't call for the $_POST['gender'] variable i can't see how it would affect your script.
Make sure that you are sanitizing your variables though, so for first name and last name you would only really want to accept A-Za-z, space and maybe hyphens and apostrophes.
By doing this it doesn't really matter what they send to your form because most of the tags, brackets etc will be removed and any script injected won't run.
Make sure you also escape the variables before you enter them in your database, I use mysql_real_escape_string in php, but don't know any asp so you will have to look it up.

How do I suppress firefox password field completion?

I'm developing a website. I'm using a single-page web-app style, so all of the different parts of the site are AJAX'd into index.php. When a user logs in and tells Firefox to remember his username and password, all input boxes on the site get auto-filled with that username and password. This is a problem on the form to change a password. How can i prevent Firefox from automatically filling out these fields? I already tried giving them different names and ids.
Edit: Someone has already asked this. Thanks Joel Coohorn.
From Mozilla's documentation
<form name="form1" id="form1" method="post" autocomplete="off"
action="http://www.example.com/form.cgi">
[...]
</form>
http://developer.mozilla.org/en/How_to_Turn_Off_Form_Autocompletion
The autocomplete="off" method doesn't work for me. I realized firefox was injecting the saved password in the first password field it encountered, so the solution that worked for me was to create a dummy password field before the password update field and hide it. Like so:
<input type="password" style="display: none;" />
<input type="password" name="password_update" />
Have you tried adding the autocomplete="off" attribute in the input tag? Not sure if it'll work, but it is worth a try.
are all your input boxes set to type=password? That would do it. One of the things you can do, and I'm not at all sure that this is the best answer is to leave input box as an input type and just use javascript and onkeydown event to place stars in the input box instead of having the browser render it. Firefox won't pre-fill that.
As an aside, I have had to work on single-page web-apps and I absolutely hate it. Why would you want to take away the user's ability to bookmark pages? To use the back button?
Adding to this answer https://stackoverflow.com/a/30897967/1333247
This is in case you also have a User field in front of the password fields and want to disable autocompletion for it too (e.g. router web config, setting proxy User and Password).
Just create a dummy user field in front of the dummy password field to hide user name autocompletion:
<input type="text" style="display: none;" />
<input type="password" style="display: none;" />
<input type="password" name="password_update" />
Per the docs this is about the Login autocompletion. To disable the normal one (e.g. search terms completion), just use the
autocomplete="off"
attribute on the form or inputs. To disable both you need both, since the attribute won't disable Login autocompletion.

How do you disable browser autocomplete on web form field / input tags?

How do you disable autocomplete in the major browsers for a specific input (or form field)?
Firefox 30 ignores autocomplete="off" for passwords, opting to prompt the user instead whether the password should be stored on the client. Note the following commentary from May 5, 2014:
The password manager always prompts if it wants to save a password. Passwords are not saved without permission from the user.
We are the third browser to implement this change, after IE and Chrome.
According to the Mozilla Developer Network documentation, the Boolean form element attribute autocomplete prevents form data from being cached in older browsers.
<input type="text" name="foo" autocomplete="off" />
In addition to setting autocomplete=off, you could also have your form field names be randomized by the code that generates the page, perhaps by adding some session-specific string to the end of the names.
When the form is submitted, you can strip that part off before processing them on the server-side. This would prevent the web browser from finding context for your field and also might help prevent XSRF attacks because an attacker wouldn't be able to guess the field names for a form submission.
Most of the major browsers and password managers (correctly, IMHO) now ignore autocomplete=off.
Why? Many banks and other "high security" websites added autocomplete=off to their login pages "for security purposes" but this actually decreases security since it causes people to change the passwords on these high-security sites to be easy to remember (and thus crack) since autocomplete was broken.
Long ago most password managers started ignoring autocomplete=off, and now the browsers are starting to do the same for username/password inputs only.
Unfortunately, bugs in the autocomplete implementations insert username and/or password info into inappropriate form fields, causing form validation errors, or worse yet, accidentally inserting usernames into fields that were intentionally left blank by the user.
What's a web developer to do?
If you can keep all password fields on a page by themselves, that's a great start as it seems that the presence of a password field is the main trigger for user/pass autocomplete to kick in. Otherwise, read the tips below.
Safari notices that there are 2 password fields and disables autocomplete in this case, assuming it must be a change password form, not a login form. So just be sure to use 2 password fields (new and confirm new) for any forms where you allow
Chrome 34, unfortunately, will try to autofill fields with user/pass whenever it sees a password field. This is quite a bad bug that hopefully, they will change the Safari behavior. However, adding this to the top of your form seems to disable the password autofill:
<input type="text" style="display:none">
<input type="password" style="display:none">
I haven't yet investigated IE or Firefox thoroughly but will be happy to update the answer if others have info in the comments.
Sometimes even autocomplete=off would not prevent to fill in credentials into the wrong fields, but not a user or nickname field.
This workaround is in addition to apinstein's post about browser behavior.
Fix browser autofill in read-only and set writable on focus (click and tab)
<input type="password" readonly
onfocus="this.removeAttribute('readonly');"/>
Update:
Mobile Safari sets cursor in the field, but it does not show the virtual keyboard. The new fix works like before, but it handles the virtual keyboard:
<input id="email" readonly type="email" onfocus="if (this.hasAttribute('readonly')) {
this.removeAttribute('readonly');
// fix for mobile safari to show virtual keyboard
this.blur(); this.focus(); }" />
Live Demo https://jsfiddle.net/danielsuess/n0scguv6/
// UpdateEnd
Because the browser auto fills credentials to wrong text field!?
I notice this strange behavior on Chrome and Safari, when there are password fields in the same form. I guess the browser looks for a password field to insert your saved credentials. Then it auto fills (just guessing due to observation) the nearest textlike-input field, that appears prior the password field in the DOM. As the browser is the last instance and you can not control it.
This readonly-fix above worked for me.
The solution for Chrome is to add autocomplete="new-password" to the input type password. Please check the example below.
Example:
<form name="myForm"" method="post">
<input name="user" type="text" />
<input name="pass" type="password" autocomplete="new-password" />
<input type="submit">
</form>
Chrome always autocomplete the data if it finds a box of type password, just enough to indicate for that box autocomplete = "new-password".
This works well for me.
Note: make sure with F12 that your changes take effect. Many times, browsers save the page in the cache, and this gave me a bad impression that it did not work, but the browser did not actually bring the changes.
<form name="form1" id="form1" method="post"
autocomplete="off" action="http://www.example.com/form.cgi">
This will work in Internet Explorer and Mozilla Firefox. The downside is that it is not XHTML standard.
As others have said, the answer is autocomplete="off".
However, I think it's worth stating why it's a good idea to use this in certain cases as some answers to this and duplicate questions have suggested it's better not to turn it off.
Stopping browsers storing credit card numbers shouldn't be left to users. Too many users won't even realize it's a problem.
It's particularly important to turn it off on fields for credit card security codes. As this page states:
"Never store the security code ... its value depends on the presumption that the only way to supply it is to read it from the physical credit card, proving that the person supplying it actually holds the card."
The problem is, if it's a public computer (cyber cafe, library, etc.), it's then easy for other users to steal your card details, and even on your own machine a malicious website could steal autocomplete data.
Always working solution
I've solved the endless fight with Google Chrome with the use of random characters. When you always render autocomplete with random string, it will never remember anything.
<input name="name" type="text" autocomplete="rutjfkde">
Hope that it will help to other people.
Update 2022:
Chrome made this improvement: autocomplete="new-password" which will solve it but I am not sure, if Chrome change it again to different functionality after some time.
I'd have to beg to differ with those answers that say to avoid disabling auto-complete.
The first thing to bring up is that auto-complete not being explicitly disabled on login form fields is a PCI-DSS fail. In addition, if a users' local machine is compromised then any autocomplete data can be trivially obtained by an attacker due to it being stored in the clear.
There is certainly an argument for usability, however there's a very fine balance when it comes to which form fields should have autocomplete disabled and which should not.
Three options:
First:
<input type='text' autocomplete='off' />
Second:
<form action='' autocomplete='off'>
Third (JavaScript code):
$('input').attr('autocomplete', 'off');
This works for me.
<input name="pass" type="password" autocomplete="new-password" />
We can also use this strategy in other controls like text, select etc
In addition to
autocomplete="off"
Use
readonly onfocus="this.removeAttribute('readonly');"
for the inputs that you do not want them to remember form data (username, password, etc.) as shown below:
<input type="text" name="UserName" autocomplete="off" readonly
onfocus="this.removeAttribute('readonly');" >
<input type="password" name="Password" autocomplete="off" readonly
onfocus="this.removeAttribute('readonly');" >
On a related or actually, on the completely opposite note -
"If you're the user of the aforementioned form and want to re-enable
the autocomplete functionality, use the 'remember password'
bookmarklet from this bookmarklets
page. It removes
all autocomplete="off" attributes from all forms on the page. Keep
fighting the good fight!"
Just set autocomplete="off". There is a very good reason for doing this: You want to provide your own autocomplete functionality!
None of the solutions worked for me in this conversation.
I finally figured out a pure HTML solution that doesn't require any JavaScript, works in modern browsers (except Internet Explorer; there had to at least be one catch, right?), and does not require you to disable autocomplete for the entire form.
Simply turn off autocomplete on the form and then turn it ON for any input you wish it to work within the form. For example:
<form autocomplete="off">
<!-- These inputs will not allow autocomplete and Chrome
won't highlight them yellow! -->
<input name="username" />
<input name="password" type="password" />
<!-- This field will allow autocomplete to work even
though we've disabled it on the form -->
<input name="another_field" autocomplete="on" />
</form>
I've been trying endless solutions, and then I found this:
Instead of autocomplete="off" just simply use autocomplete="false"
As simple as that, and it works like a charm in Google Chrome as well!
We did actually use sasb's idea for one site.
It was a medical software web app to run a doctor's office. However, many of our clients were surgeons who used lots of different workstations, including semi-public terminals. So, they wanted to make sure that a doctor who doesn't understand the implication of auto-saved passwords or isn't paying attention can't accidentally leave their login information easily accessible.
Of course, this was before the idea of private browsing that is starting to be featured in Internet Explorer 8, Firefox 3.1, etc. Even so, many physicians are forced to use old school browsers in hospitals with IT that won't change.
So, we had the login page generate random field names that would only work for that post. Yes, it's less convenient, but it's just hitting the user over the head about not storing login information on public terminals.
I think autocomplete=off is supported in HTML 5.
Ask yourself why you want to do this though - it may make sense in some situations but don't do it just for the sake of doing it.
It's less convenient for users and not even a security issue in OS X (mentioned by Soren below). If you're worried about people having their passwords stolen remotely - a keystroke logger could still do it even though your app uses autcomplete=off.
As a user who chooses to have a browser remember (most of) my information, I'd find it annoying if your site didn't remember mine.
The best solution:
Prevent autocomplete username (or email) and password:
<input type="email" name="email"><!-- Can be type="text" -->
<input type="password" name="password" autocomplete="new-password">
Prevent autocomplete a field:
<input type="text" name="field" autocomplete="nope">
Explanation:
autocomplete continues work in <input>, autocomplete="off" does not work, but you can change off to a random string, like nope.
Works in:
Chrome: 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63 and 64
Firefox: 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57 and 58
Use a non-standard name and id for the fields, so rather than "name" have "name_". Browsers will then not see it as being the name field.
The best part about it is that you can do this to some, but not all, fields and it will autocomplete some, but not all fields.
Adding autocomplete="off" is not going to cut it.
Change the input type attribute to type="search".
Google doesn't apply auto-fill to inputs with a type of search.
I just ran into this problem and tried several failures, but this one works for me (found on MDN):
In some cases, the browser will keep suggesting autocompletion values
even if the autocomplete attribute is set to off. This unexpected
behavior can be quite puzzling for developers. The trick to really
force the no-completion is to assign a random string to the attribute
like so:
autocomplete="nope"
Adding the
autocomplete="off"
to the form tag will disable the browser autocomplete (what was previously typed into that field) from all input fields within that particular form.
Tested on:
Firefox 3.5, 4 BETA
Internet Explorer 8
Chrome
So here is it:
function turnOnPasswordStyle() {
$('#inputpassword').attr('type', "password");
}
<input oninput="turnOnPasswordStyle()" id="inputpassword" type="text">
In order to avoid the invalid XHTML, you can set this attribute using JavaScript. An example using jQuery:
<input type="text" class="noAutoComplete" ... />
$(function() {
$('.noAutoComplete').attr('autocomplete', 'off');
});
The problem is that users without JavaScript will get the autocomplete functionality.
This is a security issue that browsers ignore now. Browsers identify and store content using input names, even if developers consider the information to be sensitive and should not be stored.
Making an input name different between 2 requests will solve the problem (but will still be saved in browser's cache and will also increase browser's cache).
Asking the user to activate or deactivate options in their browser's settings is not a good solution. The issue can be fixed in the backend.
Here's the fix. All autocomplete elements are generated with a hidden input like this:
<?php $r = md5(rand() . microtime(TRUE)); ?>
<form method="POST" action="./">
<input type="text" name="<?php echo $r; ?>" />
<input type="hidden" name="__autocomplete_fix_<?php echo $r; ?>" value="username" />
<input type="submit" name="submit" value="submit" />
</form>
The server then processes the post variables like this: (Demo)
foreach ($_POST as $key => $val) {
$newKey = preg_replace('~^__autocomplete_fix_~', '', $key, 1, $count);
if ($count) {
$_POST[$val] = $_POST[$newKey];
unset($_POST[$key], $_POST[$newKey]);
}
}
The value can be accessed as usual
echo $_POST['username'];
And the browser won't be able to suggest information from the previous request or from previous users.
This will continue to work even if browsers update their techniques to ignore/respect autocomplete attributes.
Try these too if just autocomplete="off" doesn't work:
autocorrect="off" autocapitalize="off" autocomplete="off"
I can't believe this is still an issue so long after it's been reported. The previous solutions didn't work for me, as Safari seemed to know when the element was not displayed or off-screen, however the following did work for me:
<div style="height:0px; overflow:hidden; ">
Username <input type="text" name="fake_safari_username" >
Password <input type="password" name="fake_safari_password">
</div>
None of the hacks mentioned here worked for me in Chrome.
There's a discussion of the issue here: https://code.google.com/p/chromium/issues/detail?id=468153#c41
Adding this inside a <form> works (at least for now):
<div style="display: none;">
<input type="text" id="PreventChromeAutocomplete" name="PreventChromeAutocomplete" autocomplete="address-level4" />
</div>
Things had changed now as I tried it myself old answers no longer work.
Implementation that I'm sure it will work. I test this in Chrome, Edge and Firefox and it does do the trick. You may also try this and tell us your experience.
set the autocomplete attribute of the password input element to "new-password"
<form autocomplete="off">
....other element
<input type="password" autocomplete="new-password"/>
</form>
This is according to MDN
If you are defining a user management page where a user can specify a new password for another person, and therefore you want to prevent autofilling of password fields, you can use autocomplete="new-password"
This is a hint, which browsers are not required to comply with. However modern browsers have stopped autofilling <input> elements with autocomplete="new-password" for this very reason.