1.4.0

Changes

• Fixed #82 . Now it's possible to use URLs relying on the "relative" protocol (example: <script src='//cdn.com/jquery.js></script>')

Autogenerated Changelog

• feat: allow relative protocol by @castarco in #94

Full Changelog: 1.3.8...1.4.0

1.3.8

Fixes

• Fixed issue #55 , now Astro-Shield can't accidentally duplicate the crossorigin attribute.

Automated Changelog

• fix: duplicated crossorigin attr by @castarco in #93

Full Changelog: 1.3.7...1.3.8

1.3.7

Changes

• Updated development dependencies
• Refactored build system, now Astro-Shield will be 100% TypeScript, and properly transpiled before packaging.
• Introduced new TS rules to make type checking a bit stricter.

Autogenerated Changelog

• chore: upgrade dependencies by @castarco in #87
• ci: dependabot.yml by @castarco in #88
• chore: make ts checks stricter by @castarco in #91
• refactor: switch to typescript by @castarco in #92

Full Changelog: 1.3.6...1.3.7

1.3.6

Fixes

• This release fixes an issue present in generated CSP directives : #76

Autogenerated Changelog

• docs: add missing license headers by @castarco in #74
• chore: upgrade pnpm by @castarco in #75
• chore: upgrade deps by @castarco in #78
• fix: csp headers generation by @castarco in #79

Full Changelog: 1.3.5...1.3.6

1.3.5

Security

• Limit postinstall scripts for the development repository. In principle, this doesn't directly affect the distributed code of this library, but it helps to reduce some supply chain risks.

Autogenerated Changelog

• security: limit postinstall scripts by @castarco in #73

Full Changelog: 1.3.4...1.3.5

1.3.4

Security improvements

• The script matcher now is able to detect malformed closing tags (containing "pseudo-attributes" that shouldn't be there according to the spec). This lets Astro-Shield to be more effective at removing a wider range of malicious injected scripts from dynamically generated content.
• Some regular expressions have been reworked to mitigate the possibility polynomial or exponential execution time. This helps to prevent the possibility of DoS attacks via specially crafted strings intended to blow up the execution time of parsing code.

Autogenerated Changelog

• docs: enable sri in docs site by @castarco in #61
• chore: optimise docs site local build by @castarco in #62
• fix: capture a wider range of malicious input by @castarco in #68

Full Changelog: 1.3.3...1.3.4

1.3.3

Minor fixes

• The previous release (1.3.2) introduced a minor warning message that, although not really problematic, was quite annoying. That was fixed.

Autogenerated Changelog

• fix: vite warning by @castarco in #60

Full Changelog: 1.3.2...1.3.3

1.3.2

Fixes

• In previous releases, the introduction of allow-lists introduced a strange regression causing the generation of an inconsistent hashes module. This has been fixed now.

Security

• This release contains important security fixes. It is advisable to upgrade as soon as possible.

Autogenerated Changelog

• fix: ensure that allowed scripts are in hashes module by @castarco in #58
• fix: do not trust integrity attribute when undeserved by @castarco in #59

Full Changelog: 1.3.1...1.3.2

1.3.1

Development

• Configure monorepo

Documentation

• Moved documentation from the README.md file to https://astro-shield.kindspells.dev

Autogenerated Changelog

• docs: fix spacing problems in README by @castarco in #48
• refactor: create pnpm workspace by @castarco in #49
• Setup monorepo by @castarco in #50
• docs: create starlight docs site by @castarco in #53

Full Changelog: 1.3.0...1.3.1

1.3.0

Security Fixes

If you were using Astro-Shield 1.2.0, it is quite relevant to upgrade to this new 1.3.0 version.

In this release we introduce many mitigations to some risks that were accidentally introduced in the past release with the new CSP headers generation for SSR content.

• Now it will be mandatory to explicitly allow-list any cross-origin resource that might be loaded from dynamically generated pages. This is necessary to avoid the possibility that Astro-Shield accidentally "signs" malicious injected scripts or stylesheets.
• It will also be possible to disallow SRI hashes generation for inline scripts or stylesheets, although we still allow them by default (we could change the default behavior in future releases, but we didn't want to introduce too many disruptive changes in a single release). The reason to disallow inline scripts in SSR content is the same as for the previous point, to protect the site against potential injections.

Other Changes

• We introduced a new way to define the SRI configuration, while keeping the old way for now (with warning messages about future deprecation).

Autogenerated Changelog

• docs: fix info box by @castarco in #44
• security: fix for major vulnerabilities by @castarco in #45

Full Changelog: 1.2.0...1.3.0