Security Tip: HTML autocomplete Attribute

[Tip#52] HTML has a lot of hidden gems, and the `autocomplete` attribute is no exception. Lets take a look at how it helps your password fields and password managers work together!

Security Tip: HTML autocomplete Attribute

Greetings my friends! This week was supposed to be an In Depth, but I’ve decided to swap it with next week’s Security Tip because the Laracon US talk recordings should be out next week, and I’d like to dive into the details of my talk1.

This week we’re looking at the HTML `autocomplete` attribute, and how best to configure it it on your password fields. This is an incredibly important attribute, as it allows your users to use password managers, which makes for a better experience and more security.

⚠️ Need to do compliance certifications, or show your clients you take security seriously? Book in a Laravel Security Audit and Penetration Test! I can help you resolve any issues discovered, and provide full reports to keep your clients happy. 🕵️

Please consider sharing Securing Laravel with your Laravel friends and teammates!

HTML autocomplete Attribute

The HTML `autocomplete` attribute is an incredibly useful attribute from a security point of view, as it allows you to help password managers interact with password fields. This makes it easier for users to generate and use secure passwords, keeping their accounts (and your app) more secure. It’s also incredibly easy to add to existing projects, making it easy to implement with minimal, if any, side affects2.

<input type="password" ... autocomplete="<VALUE>">

Let’s take a look at the options you want:


Instructs the browser to not autofill anything into this field, but instead wait for a new password. This makes it harder to accidently reuse passwords across apps. This should be used on both the New Password and Confirm Password fields.

Some browsers and password managers will prompt to create and store a new secure password in this field, which makes creating accounts with secure passwords super easy.


Instructs the browser to autofill  the known current password for the site. Making the login process easy.

This works well when used alongside the `autocomplete="username"` or `autocomplete="email"` attribute on your username/email field.


Identifies One-Time-Password (OTP) fields, such as for Multi-Factor Authentication (MFA) via SMS, or App codes.

Some password managers, like 1Password, allow you to store App-based MFA tokens, so they can autofill during the login flow3. I believe SMS OTP tokens can also be autofilled on iOS?


As a special mention here, this setting is often requested on penetration tests and older compliance standards. However it is ignored by many browsers/password managers on password fields because it goes against modern password recommendations4.

There are also a bunch of `cc-*` attributes that relate to collecting credit cards, which allows the browser to safely autofill card detail. I’m not going to cover them here, but if you’re collecting card details manually, you can check those out at the MDN Docs.

Looking to learn more?
Security Tip #32: Multiple Rate Limits
▶️ OWASP In Depth: A08:2021 – Software and Data Integrity Failures

  1. I’m also absolutely smashed after being awake for 33 hours travelling to Nashville for Laracon US yesterday, and I’d rather bump an In Depth back a week than force myself to write one when I’ve limited energy.

  2. I can’t think of any negative side-affects for enabling these, but there could be some very specific cases… maybe…?

  3. There is a different security discussion around storing your MFA tokens in a password manager alongside the password. Reach out if you want to dive into it.

  4. Preventing autocompleting passwords encourages users to reuse terrible passwords and is terrible advice. If your penetration test recommends disabling autocomplete for passwords, you really need to find a better company to do your next test.

    (No, I’m not just saying this because I do penetration tests… 🤣)