Unfortunately, CORS isn't a magic bullet. Suppose a site named evil.example adds a script tag pointing to http://localhost:1234/promnesia.js and a victim loads evil.example. If your JS updates a DOM element with info from the database, evil.example's JS can read that DOM element and report it back to the server, without violating CORS.
Ah I see, thanks! Good point, and I guess basic auth would protect against such sort of attack.
So it seems it makes sense to use a token even if it's running as localhost, I could add an option, so it doesn't require setting up a separate proxy.
Either way, I hope I've been fairly reasonable about security so far, but I've mostly been concentrating on the 'plugging in the data' bit, so it's possible I've overlooked something (also I'm not a security specialist!). There is an open issue in case people have any specific concerns or spot something, happy to receive feedback! https://github.com/karlicoss/promnesia/issues/14
I think it's becoming clear that the whole 'local web server to do system things for a browser extension' approach is probably too fraught and should be abandoned for better IPC mechanism that browsers support. I don't think this is some 'drop everything and rewrite stuff' thing but it's worth reading up on and planning for.
Yeah, possibly. Chrome actually has something called "native messaging" https://developer.chrome.com/apps/nativeMessaging which seems like a potentially more secure (and faster?) alternative, but I haven't had time to play with it yet.
Yep, that's one of the things I had in mind when mumbling about 'better IPC'. Safari already only supports that type of model. I think the day is not far when automated scans/app stores/etc start flagging the local http server thing as high risk/potential malware vector. It's an architectural dead-end.
On the other hand, some of the other stuff may not be fully baked:
To follow up: the solution is that the localhost server needs to make sure each API call is authorized (if you aren't already). This means there must be a login/setup step.
An API call can't be considered authorized just because it came from localhost :)
