Practical Security: Browser Security Settings

This series of blog posts will aim to look at some “quick wins”, which an organisation or a security team (or even interested users) can realistically put into place immediately, what they are, and how they impact both security and usability.

This is not aimed at being remotely comprehensive, or reaching a “perfect” state of security – while a few people might browse the Internet with non-HTML non-image content off by default, we realize this probably isn’t feasible for most users, and having an actual Security Policy based on what you actually need is a Really Good Idea [tm].

While most people (and by extension, organisations) simply take their browser for granted, modern browsers typically have a slew of settings (not necessarily explicitly related to security) which can impact the security context for end-users. Here are a few “quick win” solutions which can easily be put in place, with minimal impact for users.

Without further ado…

Delete Cookies on Logout

Where: Chrome Settings, Show Advanced Settings, Content Settings / Firefox Preferences, Privacy, Use custom settings for history (The “Always use private browsing” mode forces Firefox to delete cookies on logout)


By default, browsers may be configured to store cookies even after a browser has been closed. This is a security risk, especially if people leave their screens unlocked, because it’s really easy for someone malicious to open up their web browser and go straight to that person’s, say, personal Gmail (and find it still logged in to all of that person’s Gmail accounts, because why would you use a separate browser for personal email, right?)

Don’t Save Passwords

Where: Chrome Settings, Show Advanced Settings, Privacy Settings Section / Firefox Preferences, Security

Browsers often offer the functionality to save user passwords on different sites. While this might be fantastic from a usability perspective, this makes things really usable for an attacker as well. Two-factor / multi-factor authentication may go some of the way to mitigate this, but often, the most important assets are stored on systems which may not necessarily support two-factor authentication.  How many of you use two-factor / multi-factor authentication on say, your CRM system, or an internal wiki? (If it’s even supported?)

Don’t Save Form Data

Where: Chrome Settings, Show Advanced Settings, Privacy Settings / Firefox Preferences, Security, Use custom settings for history (The “Always use private browsing” mode forces Firefox to not store form data)


This is a no-brainer, like the above: this time, instead of storing passwords, browsers will typically offer to store form data for users as well. Again, from a usability perspective, this can be great for storing things like people’s home address for the amazon shopping they did at lunch, people’s personal details for accounts they sign up for (email, name, contact number, private email, date of birth) and a slew of other potentially embarrassing (or even security-sensitive) information. From a security perspective, none of this is information you want lying around on your user’s hard-drives, ready to be accessed by the first person to find them with their screen unlocked.

Click-To-Play Plugins

Where: Chrome Settings, Show Advanced Settings, Content Settings, Plug-ins (Click to play) / Firefox: Navigate to about:config, promise to be careful, search for “plugins.click_to_play”

This one is controversial, because of the impact it has on the user experience, and how people end up using this option. Many modern websites rely on plugins to deliver functionality, but some malicious sites will rely on them to deliver a payload. Click to play gives users some degree of control over the issue, by preventing these plugins from running automatically, until a user gives approval.

Theoretically, users will make an informed decision, but typically, many users will treat it as a game of whack-a-mole and enable every plugin they see, if only for fun. Still, it’s recommended to enable Click to Play – and to simply inform users of which plugins you know about, and/or when it’s safe to add a site-wide exception.

For fun…

If you’re interested in what your Firefox is actually storing (i.e. why are you using a whole 350MB of cache) you may be interested in the following tool, by a fellow Gentleman Scholar by the name of Andy:

About Norman

Sometimes, I write code. Occasionally, it even works.
This entry was posted in Bards, Computers, Jesting. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.