# Fixing Subresource Integrity Hashes

**URL:** <https://zola.discourse.group/t/fixing-subresource-integrity-hashes/825>\
**Category:** Feature requests\
**Created:** [March 11, 2021, 10:16pm UTC](https://zola.discourse.group/t/fixing-subresource-integrity-hashes/825 "2021-03-11T22:16:39Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![sstelfox](https://yyz2.discourse-cdn.com/free1/user_avatar/zola.discourse.group/sstelfox/32/464_2.png) [@sstelfox](https://zola.discourse.group/u/sstelfox)\
**Post date:** [March 11, 2021, 10:16pm UTC](https://zola.discourse.group/t/fixing-subresource-integrity-hashes/825/1 "2021-03-11T22:16:39Z")

</div>

I began adding subresource integrity and ran into an issue. The sample found in  
[the documentation](https://www.getzola.org/documentation/templates/overview/) does not produce a valid subresource integrity hash:

```auto
<script src="{{ get_url(path="js/app.js") }}" integrity="sha384-{{ get_file_hash(path="js/app.js", sha_type=384) }}"></script>

```

This check is failing as the `get_file_hash()` method is returning a hex-encoded  
version of the digest instead of a base64 encoded version as defined in the  
[official spec](https://w3c.github.io/webappsec-subresource-integrity/#the-integrity-attribute) and MDN.

I haven’t contributed to Zola before, but happy to open a PR with a fix and  
update the documentation. The way I see it there are a couple of different  
paths to getting to a point where valid integrity hashes could be generated.

The most flexible would likely to be to add two more built-in filters  
`hex_encode` and `hex_decode` to match the existing `base64_encode` and  
`base64_decode`. This doesn’t change any existing usage, and is potentially  
useful for other things. An updated integrity attribute can be generated like  
this:

```auto
<script src="{{ get_url(path="js/app.js") }}" integrity="sha384-{{ get_file_hash(path="js/app.js", sha_type=384) | hex_decode | base64_encode }}"></script>

```

Not very ergonomic but it does work. The next reasonable option would be to add  
another optional argument to the existing `get_file_hash()` method such as  
`encoding` allowing you to specify a base64 encoding instead of a hex decoding.  
The resulting usage would look something like the following:

```auto
<script src="{{ get_url(path="js/app.js") }}" integrity="sha384-{{ get_file_hash(path="js/app.js", sha_type=384, encoding=base64) }}"></script>

```

This seems like a relatively small change and shouldn’t have any impact on any  
existing usage as long as encoding defaults to `hex`. The last idea is the most  
ergonomic from a user’s perspective, use a dedicated helper for generating the  
integrity string. I suspect this falls foul of keeping the feature set minimal,  
but wanted to include it as an option anyway. Effectively this would behave the  
same way as the existing `get_file_hash` but properly format the result  
specifically for an integrity attribute:

```auto
<script src="{{ get_url(path="js/app.js") }}" integrity="{{ get_file_integrity(path="js/app.js", sha_type=384) }}"></script>

```

All of those options seem like they would be quite quick to implement, and easy  
enough to update the documentation at the same time. What direction seems most  
appropriate?

---

<div class="post-metadata">

**Author:** ![keats](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@keats](https://zola.discourse.group/u/keats)\
**Post date:** [March 12, 2021, 7:19am UTC](https://zola.discourse.group/t/fixing-subresource-integrity-hashes/825/2 "2021-03-12T07:19:19Z")

</div>

This is already fixed in 0.14: [Next version by Keats · Pull Request #1293 · getzola/zola · GitHub](https://github.com/getzola/zola/pull/1293/commits/d3ab3936de8657ee405693b7ed79790af90a313f)

---

<div class="post-metadata">

**Author:** ![sstelfox](https://yyz2.discourse-cdn.com/free1/user_avatar/zola.discourse.group/sstelfox/32/464_2.png) [@sstelfox](https://zola.discourse.group/u/sstelfox)\
**Post date:** [March 12, 2021, 2:25pm UTC](https://zola.discourse.group/t/fixing-subresource-integrity-hashes/825/3 "2021-03-12T14:25:05Z")

</div>

Oh awesome. I couldn’t find that when I searched. Glad to see it’s already been tackled!