Firewalling Your Code (lackofimagination.org)
from Aijan@programming.dev to programming@programming.dev on 21 Aug 2024 09:33
https://programming.dev/post/18394465

#programming

threaded - newest

LainTrain@lemmy.dbzer0.com on 21 Aug 2024 11:28 next collapse

More hellish complexity

gencha@lemm.ee on 21 Aug 2024 11:44 next collapse

Now that is ancient js style

fubarx@lemmy.ml on 21 Aug 2024 14:19 next collapse

Excellent domain name!

grandel@lemmy.ml on 27 Aug 2024 21:12 collapse

I think its lacking of imagination

petey@aussie.zone on 21 Aug 2024 23:37 next collapse

I love that you’re thinking about how to secure sensitive parts of JS applications, however I wonder what threat this is guarding against. Can you give an example? Surely if an attacker can modify the source to call the sensitive functions, then they could modify the allow list

hosaka@programming.dev on 22 Aug 2024 01:11 collapse

I think it’s is not aimed to protect against potential attacks, this is aimed at a developer using/writing modules of code. This is not a security guard

petey@aussie.zone on 22 Aug 2024 05:17 collapse

Ah ok, the name implies it’s a security guard

31337@sh.itjust.works on 22 Aug 2024 11:21 next collapse

I think similar, and arguably more fine-grained, things can be done with Typescript, traditional OOP (interfaces, and maybe the Facade pattern), and perhaps dependency injection.

Jayjader@jlai.lu on 25 Aug 2024 08:44 collapse

The idea is neat, and there is a certain precedent for the approach in .htaccess files and webserver path permissions.

Still, I worry about the added burden to keeping track of filenames when they get used as stringed keys in such a manner. More plainly: if I rename a file, I now have to go change every access declaration that mentions it. Sure, a quick grep will probably do the trick. But I don’t see a way to have tooling automate any part of it, either.