Hi all. I made a self-hosted API for CRUD-ing JSON files. Built for data storage in small personal projects, or mocking an API for development. Advantages are simplicity, interoperability and performance (using the cache system).
API is based on your JSON structure. So the example below is for CRUD-ing [geralt][city] in file.json. The value (which can be anything) is then added to the body of the request. For me, it has been really flexible and useful, so I want to share it and collect feedback!
Thanks for checking my project out. In the readme I state it’s for ‘small personal projects’ where you want to get something quickly. However, “widly insecure” seems a bit much? If you use it for storing data that has no privacy (like public blog posts, and their comments)?
You try using “…/…/…/…/…/etc/passwd” as the filename in your requests? I don’t see anywhere where ‘…’ is escaped or removed from file strings. Sending untrusted filenames directly to file operations without scrubbing and sanity checking is very dangerous and potentially allows a malicious user to read and overwrite any files the application has permissions for.
I think that’s a valid point. Note, the API is structured: /file/key1/key2/… if you want to access [key1][key2] in file.json. Hence, you can’t have folder paths in the filename (because that adds an additional slash). However, perhaps with escaping characters it might become possible, so I made an issue to fix this 👍
Btw, I appreciate you taking the time to investigate and understand my side project. It really helps. Happy 2026! (in my timezone we’re almost there).
Ah - I missed that other parms were keys. Still - best practice is to sanitize all user inputs. Try throwing lots of file-path-like args at it to see what it does. it’s a historically tricky problem so there should be some libraries that help with it.
Happy 2026! And happy hacking!
You know what? Rather than over-complicate things you can probably just check that filenames only contain a small set of white-listed chars. [a-zA-z-._] (and != ‘…’ or ‘.’) or something.
And one other nit-pick if you’re up for more code-review - your authentication logic should probably be inverted:
if !ok || user != session.config.username || pass != session.config.passwordI’d change that to be something like
if ok && user == session.config.username && pass == session.config.password { // do login } else { // not auth }There’s a whole category of security errors where an exception in logic like that causes the code to skip the “you’re not allowed” logic and go right to the “you’re allowed!” block. It’s more of an issue with languages that support exceptions but it’s still considered a best practice generally (it’s also typically easier to read).