Closed hrbrmstr closed 7 years ago
Your involvement was actually my plan all along, so I'm very happy for this issue😊
My overarching plan is to make fiery so barebone as possible, but then have a "firesafety" package that would take care of all the sensible, security related, stuff, e.g. setting the correct headers to avoid cross-site-scripting attacks. You help with that would be an absolute boon!
Count me in! If it wasn't obvious, I'm finding this to be a super useful pkg (while plumber
is nice and all, the lack of decorators being a language feature makes me hesitant to use it). I'm going to try to wire up log4r
with it in another post
Fantastic. My current plan is to be very inspired by http://expressjs.com/en/advanced/best-practice-security.html but this is mainly because I'm very new to Infosec and need inspiration. I'll push an empty repo to GitHub and give you editing rights.
Btw if there are design problems in fiery itself, security wise, these should of course be fixed there
Also making a note here to get @jsonbecker looped into this project once it gets kicking again.
I sense the pressure mounting😉
Closing this - all security features should be addressed in firesafety
(https://github.com/thomasp85/firesafety). If there are safety issues inherent to the the way fiery is programmed, it should get a new issue
Interested in a hand from someone far too entrenched in infosec?
I just started looking at this and will keep this list up to date but for starters:
host
should default to127.0.0.1
and absolutely not0.0.0.0
. I can go into "why" but this is pretty much the standard best practice (hate that term) and the only way to help users not shoot themselves in the foot.