Inability to upload files with a .har extention to an Incident record

[Edward Rosario]

The other day, I was helping someone who needed to attach a .har file to an incident in ServiceNow. Simple enough, right? Just drag and drop the file. But nope — ServiceNow wasn’t having it. The upload was blocked, and the user was stuck.

At first, I thought, “Okay, it’s probably the file extension thing.” ServiceNow has a property called glide.attachment.extensions that controls which file extensions are allowed. If you list out extensions there (like pdf, xls, doc), ServiceNow only accepts those. If you leave it blank, it should accept everything.

In this case, it was blank. So extensions weren’t the problem.

Digging Deeper

That’s when I remembered another property that can mess with uploads: glide.security.file.mime_type.validation.

When this one is turned on, ServiceNow doesn’t just look at the extension — it actually checks the file’s MIME type (what the browser says the file is). Then it compares that against the System MIME Types table (sys_mime_type).

And if it doesn’t find a match? Blocked.

That’s exactly what was happening here. .har files usually come through as application/json or sometimes application/octet-stream, but ServiceNow had no idea what to do with .har. Since there was no entry for it in the MIME type list, the upload got denied.

The Fix

Once I figured that out, the solution was straightforward:

• The “clean” fix was to add .har to the MIME Types table with something like:
• Extension: har
• MIME type: application/json
• The “quick but not great” fix would be to turn off glide.security.file.mime_type.validation. That works too, but it lowers security, so I wouldn’t recommend it unless you’re just testing.

Lesson Learned

What I took away from this is that ServiceNow attachments aren’t just about extensions. You might think leaving the extension list blank means “everything goes,” but MIME type validation can still stop you in your tracks.

So next time a file won’t attach, I’ll know to check both places — and not just blame the poor extension list.

[MortenPettersen]

Greetings Edward

It sounds like you had a challenge but already solved it then, thanks for sharing it with the rest of us. My question then goes beyond the technical aspect of it. I'm curious to why it was necessary to upload a .har file, and if just zipping it was considered as a viable alternative? Is it because uploading .har files now will be a regular thing to do in a specific type of workflow or process?

[NeoOndaro]

So confused. I do not see a table called sys_mime_type.

[JC Moller]

Personally I would never upload a .HAR file to a ticket or analyze its content on an online service (not even the Google service one). There are offline tools.

Atleast remove from .HAR files before adding to a ticket:
Session tokens, authorization headers, API keys, authentication cookies, passwords, email addresses, internal IP addresses, proprietary data in request/response bodies.

This is highly sensitive data, not to be added to tickets. IMHO. Several large breaches in the recent years have utilized social engineering and .HAR files provided by support.

Treat .HAR files with the same security caution as credential files or logs containing authentication data. Never share unredacted versions outside secure, authenticated channels.

- JC

[Ryan S]

@NeoOndaro I found this article https://snscout.blogspot.com/2021/02/attachment-mime-type-mapping.html which talks about a system property, not a table. It includes a link to a ServiceNow KB but of course I don't have access to the content. After creating the property as a string type and entering the <custom_extension>=text/plain I was able to upload the file that was causing me trouble. I haven't confirmed if doing this broke anything else and only had the one file type that was failing mime validation.

"So what do we do when file extensions aren't an issue and our MIME type isn't recognized? Well, we have to map the extension to a MIME type. If it doesn't yet exist, you need to create a system property called 'glide.security.mime_type.extension_mapping'. The values are comma separated using a syntax that combines the extension with the MIME type/subtype format for example: dat=application/octet-stream,dat=text/plain."