hi neat project / note on security

[kumavis]

saw your work on hn enjoyed the article and discussion

i am a javascript language security researcher in your article you mentioned this playing a role in security

enhance security by limiting the potential for unauthorized actions

if this is true, please bare in mind that these security guarantees can be easily subverted in the following ways:

• malicious naming of the source file to include the excepted firewall internal module filepath
• corrupting the Error intrinsic (overriding and preventing further overriding of prepareStackTrace) to provide inaccurate results to the callsite package
• corrupting the String.prototype.replace intrinsic to always contain the attackers filepath

if this sort of thing interests you, check out:

• our work on the Hardened JavaScript proposal and our shim for using it today
• my talk on LavaMoat, using Hardened JavaScript for software supplychain runtime protections
• our work on Endo, a secure-by-default javascript runtime

[aycangulez]

Thank you for your input and suggestions. firewall-js wasn’t originally designed to protect against supply-chain attacks but rather to ensure that the application’s architecture is properly enforced. As you pointed out, it’s not difficult to circumvent access controls if malicious code is present anywhere in the application. I think using both firewall-js and ses together makes sense for enhanced security.