{"version":"https://jsonfeed.org/version/1","title":"Aaron Gustafson: Content tagged security","description":"The latest 20 posts and links tagged security.","home_page_url":"https://www.aaron-gustafson.com","feed_url":"https://www.aaron-gustafson.com/feeds/security.json","author":{"name":"Aaron Gustafson","url":"https://www.aaron-gustafson.com"},"icon":"https://www.aaron-gustafson.com/i/og-logo.png","favicon":"https://www.aaron-gustafson.com/favicon.png","expired":false,"items":[{"id":"https://www.aaron-gustafson.com/notebook/a-web-component-for-obfuscating-form-fields/","title":"✍🏻 A Web Component for Obfuscating Form Fields","summary":"There’s no standard way to make a field readable while editing but obfuscated at rest. The form-obfuscator web component fills that gap, giving you control over how sensitive data appears when fields aren't focused.","content_html":"

We have the password reveal pattern for passwords, but what about other sensitive fields that need to be readable while editing and obfuscated while at rest? The form-obfuscator web component does exactly that.

\n

# Basic usage

\n

Wrap any text field in the component and it will automatically obfuscate the value when the field loses focus:

\n
<form-obfuscator>\n  <label for=\"secret-key-1\">What was your first pet’s name?</label>\n  <input type=\"text\" id=\"secret-key-1\" name=\"secret-key-1\" />\n</form-obfuscator>
\n

When users click into the field, they see the actual value. When they click away, it’s replaced with asterisks (*). The real value is preserved in a hidden field for form submission.

\n

# Custom obfuscation characters

\n

If you don’t like asterisks, you can specify any character you like:

\n
<form-obfuscator character=\"•\">\n  <label for=\"account\">Account Number</label>\n  <input type=\"text\" id=\"account\" name=\"account\" />\n</form-obfuscator>
\n

Or get creative:

\n
<form-obfuscator character=\"🤐\">\n  <label for=\"ssn\">Social Security Number</label>\n  <input type=\"text\" id=\"ssn\" name=\"ssn\" />\n</form-obfuscator>
\n

# Pattern-based obfuscation

\n

Sometimes you want to show part of the value while hiding the rest. The pattern attribute lets you specify which characters to keep visible:

\n
<form-obfuscator pattern=\"\\d{4}$\">\n  <label for=\"ssn\">Social Security Number</label>\n  <input type=\"text\" id=\"ssn\" name=\"ssn\" />\n</form-obfuscator>
\n

This keeps the last four digits visible while replacing everything else with your obfuscation character. Perfect for Social Security Numbers, credit cards, or phone numbers where showing the last few digits helps users confirm they’ve entered the right value.

\n

# Limiting displayed characters

\n

Use the maxlength attribute to cap how many characters appear when obfuscated:

\n
<form-obfuscator maxlength=\"4\">\n  <label for=\"password\">Password</label>\n  <input type=\"text\" id=\"password\" name=\"password\" />\n</form-obfuscator>
\n

Even if the user enters a 20-character value, only four asterisks will be displayed when the field is obfuscated. This prevents giving away information about the length of the information entered.

\n

# Custom replacement functions

\n

For complete control, you can provide a JavaScript function via the replacer attribute:

\n
<script>\n  window.emailReplacer = function () {\n    var username = arguments[0][1];\n    var domain = arguments[0][2];\n    return username.replace(/./g, \"*\") + domain;\n  };\n</script>\n\n<form-obfuscator\n  pattern=\"^(.*?)(@.+)$\"\n  replacer=\"return emailReplacer(arguments)\"\n>\n  <label for=\"email\">Email Address</label>\n  <input type=\"text\" id=\"email\" name=\"email\" value=\"user@example.com\" />\n</form-obfuscator>
\n

This example uses a pattern to separate the username from the domain, then obfuscates only the username portion, leaving @example.com visible.

\n

Here’s another practical example for credit cards:

\n
<script>\n  function cardNumberReplacer() {\n    var beginning = arguments[0][1];\n    var final_digits = arguments[0][2];\n    return beginning.replace(/\\d/g, \"*\") + final_digits;\n  }\n</script>\n\n<form-obfuscator\n  pattern=\"^((?:[\\d]+\\-)+)(\\d+)$\"\n  replacer=\"return cardNumberReplacer(arguments)\"\n>\n  <label for=\"cc\">Credit Card</label>\n  <input type=\"text\" id=\"cc\" name=\"cc\" value=\"1234-5678-9012-3456\" />\n</form-obfuscator>
\n

This displays as ****-****-****-3456, showing only the last group of digits.

\n

# Combining attributes

\n

You can combine these attributes for sophisticated obfuscation patterns:

\n
<form-obfuscator pattern=\"\\d{4}$\" character=\"•\" maxlength=\"16\">\n  <label for=\"card\">Credit Card</label>\n  <input type=\"text\" id=\"card\" name=\"card\" />\n</form-obfuscator>
\n

This keeps the last 4 digits visible, uses bullets for obfuscation, and limits the display to 16 characters total.

\n

# Event handling

\n

The component dispatches custom events when values are hidden or revealed:

\n
const obfuscator = document.querySelector(\"form-obfuscator\");\n\nobfuscator.addEventListener(\"form-obfuscator:hide\", (e) => {\n  console.log(\"Field obfuscated:\", e.detail.field.value);\n});\n\nobfuscator.addEventListener(\"form-obfuscator:reveal\", (e) => {\n  console.log(\"Field revealed:\", e.detail.field.value);\n});
\n

You can access both the visible field and the hidden field through event.detail.field and event.detail.hidden respectively.

\n

# How it works

\n

The component creates a hidden input field to store the actual value for form submission. When the visible field loses focus, it:

\n
    \n
  1. Copies the current value to the hidden field
    2. \n
  2. Applies your obfuscation rules to create the display value
    3. \n
  3. Updates the visible field with the obfuscated value
    4. \n
  4. Dispatches the form-obfuscator:hide event
    5. \n
\n

When the field gains focus, it:

\n
    \n
  1. Restores the real value from the hidden field
    2. \n
  2. Updates the visible field
    3. \n
  3. Dispatches the form-obfuscator:reveal event
    4. \n
\n

The source order ensures the hidden field is the one that gets submitted with the form.

\n

# Progressive enhancement

\n

The component makes no assumptions about your markup—it works with any text-style input element. If JavaScript fails to load, the field behaves like a normal input, which is exactly what you want. Users can still enter and submit values; they just won’t get the obfuscation behavior.

\n

# Demo

\n

I’ve created a comprehensive demo page showing the various configuration options over on GitHub:

\n
\n\n\n\n
\n

# Grab it

\n

Check out the full project over on GitHub or install via npm:

\n
npm install @aarongustafson/form-obfuscator
\n

Import and use:

\n
import \"@aarongustafson/form-obfuscator\";
\n

No dependencies, just a straightforward way to add field obfuscation to your forms.

\n","social_text":"Need to obfuscate form field values when they’re not being edited? Here’s a web component for that.","url":"https://www.aaron-gustafson.com/notebook/a-web-component-for-obfuscating-form-fields/","tags":["forms","HTML","JavaScript","progressive enhancement","web components","web forms","security"],"date_published":"2025-12-06T20:03:47Z"},{"id":"https://www.aaron-gustafson.com/notebook/spellcheckers-exfiltrating-pii_-not-so-fast/","title":"✍🏻 Spellcheckers exfiltrating PII… not so fast","summary":"A recent post from the Otto JS research team highlighted how spellcheck services can inadvertently exfiltrate sensitive user data, including passwords, from your site. To be honest, I found the post a tad alarmist and lacking when it came to recommending solid protections. Consider this your no-nonsense guide to protecting your users’ sensitive information.","content_html":"

A recent post from the Otto JS research team highlighted how spellcheck services can inadvertently exfiltrate sensitive user data, including passwords, from your site. To be honest, I found the post a tad alarmist and lacking when it came to recommending solid protections. Consider this your no-nonsense guide to protecting your users’ sensitive information.

\n

# Background

\n

In their research, the Otto JS team found that Chrome and Edge each use their own web services to drive their spellchecking services. In Chrome’s case it seems to only be with their “advanced spellcheck” feature turned on. I was able to validate this behavior using Charles on macOS Monterey using the latest Chrome Stable and the latest Edge Canary. I did not see the same exfiltration happen with Safari or Firefox. I created a CodePen form with several fields to test different permutations of form field attributes and behaviors. What I am sharing, below, is a result of that testing.

\n

# What gets sent?

\n

In both Chrome and Edge, the information sent to their services is the text value itself, disconnected from any specific field name. Chrome also sends the user’s language, and country. Edge, which uses the Microsoft Editor service under the hood, also sends a bunch of licensing details and the user’s language.

\n

# Password fields are safe

\n
<input type=\"password\" id=\"password\" name=\"password\" />
\n

Browsers do a lot to protect the contents of password fields already, so I wasn’t surprised to see that the contents of password fields are not passed to a spellcheck service.

\n

If you are not using a true password field, however, the contents of that field are not protected in the same way. If you build a custom password control, you’re on the hook to replicate the entirety of the browser’s feature set when it comes to protecting user data. Unless you’re a glutton for punishment, you should probably just use the built-in password field instead.

\n

# Fields marked readonly and disabled are not exposed

\n

As you’d hope, neither read-only fields nor disabled fields are exposed ot the service. This even holds true when you change the values of these fields programmatically or via DevTools.

\n

I should note, however, that readonly fields are send to the server when the form is submitted and their contents are editable via JavaScript and DevTools, so you should always assume readonly fields are informational for the user only and never trust their contents on the server side. Fields that are marked disabled, in contrast, are never sent to the server.

\n

# You can protect interactive fields with the spellcheck attribute

\n
<input id=\"no-spellcheck\" name=\"no-spellcheck\" spellcheck=\"false\" />
\n

The spellcheck attribute can be applied to any element and setting it to “false” instructs browsers to turn off spellchecking services for its contents. The post from Otto JS showed this being used globally on the body element, but that is overkill. It would be better to use the attribute on specific fields you want to protect, as shown above.

\n

# Don‘t forget about password controls that support show/hide

\n

Edge has a neat feature in its password field implementation where it enables a user to toggle the visibility of the password within the control itself. When users show their password using that built-in functionality, no content is shared with the spellchecker. Not all browsers have this feature, however, which has led to JavaScript-based implementations that simply swap the “password” type value for “text” to show the contents and then swap it back again to hide the contents. Here’s a quick & dirty example of what the toggle button’s event handler might look like:

\n
function togglePassword(e) {\n  var $btn = e.target,\n    $field = $btn.parentNode.querySelector(\"input\"),\n    state = $field.type;\n  if ($btn && $field) {\n    if (state == \"password\") {\n      $field.type = \"text\";\n      $btn.innerText = \"Hide\";\n    } else {\n      $field.type = \"password\";\n      $btn.innerText = \"Show\";\n    }\n    e.preventDefault();\n    e.stopPropagation();\n  }\n}
\n

The problem with this approach, when it comes to the spellchecker, is that the text field is considered fair game for checking. Its contents aren’t sent right away, but if the field receives focus or its value is changed in any way while in the “text” state, its contents are sent to the spellcheck service.

\n

Protecting the field’s contents are fairly easy, however: turn off the spellchecker for that field, even in its “password” state.

\n
<input\n  type=\"password\"\n  id=\"password-show-nospellcheck\"\n  name=\"password-show-nospellcheck\"\n  spellcheck=\"false\"\n/>
\n

With spellcheck="false" in place, you can turn the field into a text field safely, without the contents being exposed to the spellcheck service.

\n
\n

HTML is a pretty powerful language and, when wielded properly, can be an excellent tool for protecting user data, provided we use it properly. And know that you know how to protect your users’ sensitive data, minimize this tab and start filing those pull requests…

\n","social_text":"A collection of ways you can keep sensitive user data protected from accidental exfiltration.","url":"https://www.aaron-gustafson.com/notebook/spellcheckers-exfiltrating-pii_-not-so-fast/","tags":["browsers","forms","HTML","security","privacy"],"image":"https://www.aaron-gustafson.com/i/posts/2022-09-19/hero.jpg","date_published":"2022-09-19T21:34:51Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/83416-uk-researcher-says-one-line-of-code-caused-ticketmaster-breach/","title":"🔗 UK researcher says one line of code caused Ticketmaster breach","content_html":"

Third party code, people… third party code.

\n
\n

He pointed out that while Inbenta had provided Ticketmaster a customised JavaScript one-liner, the ticketing company had placed this chatbot code on its payment processing website without informing Inbenta it had done so.\n“This means that Inbenta’s webserver was placed in the middle of all Ticketmaster credit card transactions, with the ability to execute JavaScript code in customer browsers,” Beaumont said.

\n
\n

Sigh.

\n","social_text":"Third party code, people… third party code: UK researcher says one line of code caused Ticketmaster breach","url":"https://www.aaron-gustafson.com/notebook/links/83416-uk-researcher-says-one-line-of-code-caused-ticketmaster-breach/","external_url":"https://www.itwire.com/security/83416-uk-researcher-says-one-line-of-code-caused-ticketmaster-breach.html","tags":["security","JavaScript"],"image":"https://itwire.com/media/k2/items/cache/c68b5f6e7e74252721c5ad209fb798bc_XS.jpg","date_published":"2018-07-03T23:38:27Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/mobile-devs-making-the-same-security-mistakes-web-devs-made-in-the-early-2000s/","title":"🔗 Mobile Devs Making the Same Security Mistakes Web Devs Made in the Early 2000s","content_html":"

Anyone who’s seen one of my forms talks knows how adamant I am about this: you can never trust the client! Doesn’t matter if that client is a web browser or your mobile app.

\n","social_text":"Anyone who’s seen one of my forms talks knows how adamant I am about this: you can never trust the client! Doesn’t matter if that client is a web browser or your mobile app.","url":"https://www.aaron-gustafson.com/notebook/links/mobile-devs-making-the-same-security-mistakes-web-devs-made-in-the-early-2000s/","external_url":"https://www.bleepingcomputer.com/news/security/mobile-devs-making-the-same-security-mistakes-web-devs-made-in-the-early-2000s/","tags":["mobile","security"],"image":"https://www.bleepstatic.com/content/posts/2018/06/04/phone-apps.jpg","date_published":"2018-06-27T20:11:03Z"},{"id":"https://www.aaron-gustafson.com/notebook/moved-to-https/","title":"✍🏻 Moved to HTTPS","summary":"So, as much as it pains me to abandon good old fashioned HTTP, I’ve decided to lock things down a bit.","content_html":"

I’ve been complaining about “man in the middle” attacks brought on by internet service providers a bunch over the last year. The only way to keep uninvited third parties from injecting JavaScript and more—potentially screwing up your page—is to move to HTTPS. So, as much as it pains me to abandon good old fashioned HTTP, I’ve decided to lock things down a bit.

\n

I was using Github to host my site as a Github page. It worked really well given this is a static site, but you can’t run Github-hosted sites under HTTPS unless you go with their *.github.io domain name (they have a wildcard certificate for that domain). There’s been a ton of interest in Github allowing custom cert installation, but no movement yet, so… onward!1

\n

I opted to move to DigitalOcean since my consultancy recently relocated all of its sites there in a mass exodus from MediaTemple. Migrating the site was as simple as setting up the DigitalOcean server as a new “live” remote on my local git install and pushing it up there. Since it’s a static site, I didn’t have to worry too much about the server config. Apache is really great at hosting static files.

\n

With the contents in place, I went through the rather convoluted process of getting SSL set up following the instructions from DigitalOcean. I opted for the free StartSSL certificate to begin with (a rather convoluted process, but we got there in the end) and then flipped the DNS records to point to the new box. Given that the StartSSL certificate needs to be renewed every 30 days, I may opt for a paid certificate in the not too distant future.

\n

Once the DNS propagated, I had to go back and button up a few scripts that were requesting non-HTTPS content. I also had to tweak my Jekyll plugins and Rake tasks to include the legacy “http://” URLs when querying for webmentions and the like (since I didn’t want to lose those references). I also updated the Apache’s VirtualHost configuration for the non-secure site to make all traffic redirect:

\n

Redirect permanent / https://www.aaron-gustafson.com/

\n

All in all, it was a relatively painless migration. Admittedly, the initial re-build of the site (after updating the Rake tasks) did re-submit all of the webmentions I’d previously sent in order to provide the new address. If I referenced you a bunch in the past, I apologize for the flood of traffic, but it had to be done.

\n

Anyway, so now this site is running under HTTPS. If you encounter any issues, please let me know. And if you want to read a really good account of migrating a site to HTTPS, you should definitely read Jeremy Keith’s step-by-step guide.

\n
\n
\n

Footnotes

\n
    \n

  1. It’s worth noting that the source of the site will remain on Github for the forseeable future. ↩︎

    \n
    2. \n
\n
\n","url":"https://www.aaron-gustafson.com/notebook/moved-to-https/","tags":["web design","security","this site"],"date_published":"2015-09-03T20:06:03Z"}]}