add a file to record notes about security
This commit is contained in:
parent
9a0b9a90bf
commit
45fb5df39e
|
@ -0,0 +1,18 @@
|
||||||
|
|
||||||
|
Some notes about security.
|
||||||
|
|
||||||
|
honk is not currently hardened against SSRF, server side request forgery. Be
|
||||||
|
mindful of what else may be reachable on localhost or the local network if
|
||||||
|
it's not generally accessible.
|
||||||
|
|
||||||
|
How are user keys supposed to be rotated? Expired? Revoked?
|
||||||
|
|
||||||
|
The current answer is never, never, never.
|
||||||
|
|
||||||
|
If the key is only used for signing http requests, it can be be changed
|
||||||
|
basically at will. Change the key in the actor, give it a new name (to avoid
|
||||||
|
conflict with any cached keys), carry on.
|
||||||
|
|
||||||
|
Using keys to sign json is more complicated. The current practice is to name
|
||||||
|
keys with URL fragments. example.com/user#key. If the keyname is changed to
|
||||||
|
#newkey, how does one fetch the old key to verify existing data?
|
7
spec.txt
7
spec.txt
|
@ -1,3 +1,10 @@
|
||||||
|
honk spec
|
||||||
|
|
||||||
|
-- references
|
||||||
|
|
||||||
|
See security.txt for some notes on security.
|
||||||
|
|
||||||
|
-- schema
|
||||||
|
|
||||||
Some notes on the database schema. Mostly for development, but maybe useful
|
Some notes on the database schema. Mostly for development, but maybe useful
|
||||||
for administration as well.
|
for administration as well.
|
||||||
|
|
Loading…
Reference in New Issue