Tag: inlinehashes

  • New release of “inlinehashes”

    Last year, I built a small tool to detect inline styles and scripts in a given webpage/document and then calculate their hashes. It can be useful for someone trying to write a strict “Content-Security-Policy” (CSP) for pre-built websites. I described the reasoning at the time in this blog post.

    Today, I’m writing to announce that I released the version 0.0.5 of inlinehashes. The main changes are:

    • CSP directives are now displayed for each hash, helping you to know right away where to place them.
    • The --target option now uses CSP directives to filter the output instead of needing to remember any custom value.
    • New output formats were added, instead of relying just on JSON.
    Screenshot of the output of inlinehashes 0.0.5

    One problem of this version is that it only supports Python 3.11. So for other interpreter versions, you are stuck with version 0.0.4. I expect to fix this soon and make everything work for, at least, the last three versions of Python.

    You can find out more on PyPI and on the source code repo.

  • Inlineshashes: a new tool to help you build your CSP

    Content-Security-Policy (CSP) is an important mechanism in today’s web security arsenal. Is a way of defending against Cross-Site Scripting and other attacks.

    It isn’t hard to get started with or to put in place in order to secure your website or web application (I did that exercise in a previous post). However when the systems are complex or when you don’t fully control an underlying “codebase” that frequently changes (like it happens with of-the-shelf software) things can get a bit messier.

    In those cases it is harder to build a strict and simple policy, since there are many moving pieces and/or you don’t control the code development, so you will end up opening exceptions and whitelisting certain pieces of content making the policy more complex. This is specially true for inline elements, making the unsafe-inline source very appealing (its name tells you why you should avoid it).

    Taking WordPress as an example, recommended theme and plugin updates can introduce changes in the included inline elements, which you will have to review in order to update your CSP. The task gets boring very quickly.

    To help with the task of building and maintaining the CSP in the cases described above, I recently started to work on a small tool (and library) to detect, inspect and whitelist new inline changes. You can check it here or download it directly from PyPI.