While cybersecurity is often thought of in terms of databases and architecture, much of a strong security posture relies on elements in the domain of the front-end developer. For certain potentially devastating vulnerabilities like SQL injection and Cross-Site Scripting (XSS), a well-considered user interface is the first line of defense.
Here are a few areas of focus for front-end developers who want to help fight the good fight.
Control user input
A whole whack of crazy things can happen when developers build a form that fails to control user input. To combat vulnerabilities like injection, it’s important to validate or sanitize user input.
Input can be validated by constraining it to known values, such as by using semantic input types or validation-related attributes in forms. Frameworks like Django also help by providing field types for this purpose. Sanitizing data can be done by removing or replacing contextually-dangerous characters, such as by using a whitelist or escaping the input data.
While it may not be intuitive, even data that a user submits to their own area on a site should be validated. One of the fastest viruses to proliferate was the Samy worm on MySpace (yes, I’m old), thanks to code that Samy Kamkar was able to inject into his own profile page. Don’t directly return any input to your site without thorough validation or santization.
For some further guidance on battling injection attacks, see the OWASP Injection Prevention Cheat Sheet.
Beware hidden fields
Adding type="hidden" is an enticingly convenient way to hide sensitive data in pages and forms, but unfortunately not an effective one. With tools like ZapProxy and even inspection tools in plain ol’ web browsers, users can easily click to reveal tasty bits of invisible information. Hiding checkboxes can be a neat hack for creating CSS-only switches, but hidden fields do little to contribute to security.
If you must use hidden fields, here are some helpful guidelines.
Carefully consider autofill fields
When a user chooses to give you their Personally Identifiable Information (PII), it should be a conscious choice. Autofill form fields can be convenient - for both users and attackers. Exploits using hidden fields can harvest PII previously captured by an autocomplete field.
Many users aren’t even aware what information their browser’s autofill has stored up. Use these fields sparingly, and disable autofilled forms for particularly sensitive data.
It’s important to also weigh your risk profile against its trade-offs. If your project must be WCAG compliant, disabling autocomplete can break your input for different modalities. For more, see 1.3.5: Identify Input Purpose in WCAG 2.1.
Keep errors generic
While it may seem helpful to let users know whether a piece of data exists, it’s also very helpful to attackers. When dealing with accounts, emails, and PII, it’s most secure to err (🥁) on the side of less. Instead of returning “Your password for this account is incorrect,” try the more ambiguous feedback “Incorrect login information,” and avoid revealing whether the username or email is in the system.
In order to be more helpful, provide a prominent way to contact a human in case an error should arise. Avoid revealing information that isn’t necessary. If nothing else, for heaven’s sake, don’t suggest data that’s a close match to the user input.
Be a bad guy
When considering security, it’s helpful to take a step back, observe the information on display, and ask yourself how a malicious attacker would be able to utilize it. Play devil’s advocate. If a bad guy saw this page, what new information would they gain? Does the view show any PII?
Ask yourself if everything on the page is actually necessary for a genuine user. If not, redact or remove it. Less is safer.
Security starts at the front door
These days, there’s a lot more overlap between coding on the front end and the back end. To create a well-rounded and secure application, it helps to have a general understanding of ways attackers can get their foot in the front door.
Top comments (13)
Yeah, front security is pretty important, and should always be considered (and associated to back security).
I teach sometimes and one of my favored 'hack' to mind blow the students is to use the inspector to change form fields types and classes :')
"You field is secure by type AND js ? Well no more type, and no more js event {if it's based on the form class}, Now I can input whatever I want..."
Like a blog comment
or
Always add a backend verification, and prevent stuff when displaying public/user inputs !
:D
"Always add a backend verification, and prevent stuff when displaying public/user inputs !"
YELL THAT FOR THE PEOPLE IN THE BACK.
I've gotten into arguments with BE devs who think since I'm doing regex on the FE you don't need it on the back. squints eyes Then remind them you can bypass FE things if your setup doesn't account that or if there's a Man In The Middle attack, how do you safeguard the BE. I tend to remind them that the FE should be dumb as rocks with some nice bells and whistles.
--- But that last one is more of my opinion shrug
Feel free to adress them my kind regards then
and they definitly should check their databases inputs :')thepracticaldev.s3.amazonaws.com/i...
Frontend form validation is purely for UX and adds nothing to security, a malicious actor would not send the requests through the form at all but something like postman that would allow them to easily tinker with the request and send directly to the backend.
This.
Since you will always need to secure your back end, many front end developers forget that security in the front end is important, too. There could always be situations when whatever happens there is not connected to your own back end service.
It could be a post message that you have unsuspectingly set up a listener for without a sanity check for the origin. Or the user pastes content in a content-editable element (or WYSIWYG editor) unchecked. Or you have a script from a third party without at least a checksum verification.
So thanks for reminding us that we're responsible for our user's security, too, Victoria.
One section to add would be guarding against modification of JS files. Some prominent sites have had credit card numbers stolen this way.
Step one is making sure storage is secured properly (e.g. S3 permissions). An advanced move would be to generate checksums when JS files are deployed, then validate those checksums each time they’re used to ensure they haven’t changed.
Very good reminders, and a couple of things I didn't know. Thanks! :) I like the "Be a bad guy" part. A lot of people skip over that part. I call them "the optimists" in that they seem to expect that nothing can go wrong and the software will be used as they intended (now that would be a dream world... :))
A small suggestion, if I may: "PII" is only defined on its third use in the article. I had no idea what it was until I got to that third use of the acronym. Maybe I'm just not up to date on acronyms, though. :D
Whoops! My bad. Thanks for pointing it out!
"Be a bad guy" is the most tedious but often the most effective. As the developer, we know how the application works and communicates to other services. Using that to your advantage can show you your weak points.
"Managing keys" would also be great add-on. When testing, shortcutting how we access our keys is something I use to overlook when starting off. Mostly because I wasn't dealing with sensitive data. Later I read up on how AWS accounts would get exploited when developers left their access keys in public GitHub repos.. Unless you want a fat bill at end of the month, careful managing your access keys :)
Also, for disabled field, just remove the
disable attributeand edit it. Most of the time, Backend doesn't validate that field.Nice update on front sec
Great simple, straight to the point article. Junior devs will love it :).
Thank you.