Seeking Feedback on My Messenger App’s Security Setup

0
4
Asked By CuriousCactus87 On

I'm working on a messenger app as a hobby project for personal use with a few friends, and I want to ensure that I've covered security effectively. My current setup includes the following:

For the backend, I'm using Java SpringBoot and for the frontend, Angular. I'm implementing the libsignal library to handle chat encryption. All communication is secure, sent via HTTPS with a Let's Encrypt certificate, and I'm planning to run only one instance of the backend. In terms of headers, I have set X-Content-Type-Options to nosniff, strict-origin-when-cross-origin for Referrer-Policy, and I'm using Strict-Transport-Security as well.

In backend security, I'm utilizing Spring Security. Request validation requires a CSRF header, and all APIs are rate-limited per user and IP. Database operations are executed through stored procedures.

On the frontend, there are no eval() methods, and I'm only using JSON for requests and responses. I'm implementing a Content Security Policy with nonce and have everything encrypted in indexedDB and localStorage using Argon2id for key derivation. To prevent clickjacking, I've set frame-ancestors to 'none' and added policies for better cross-origin protection.

During registration, I issue a one-time key that gets deleted after use, and login will be handled through passkeys. The backend only recognizes the user, their devices, and chat info. Upon logging in, the client receives a JWT token, which is stored in a secure, HTTP-only session cookie. Device linking uses a unique 30-character code sent from the primary device.

For chat encryption, I support one-on-one and group chats, relying on the signal protocol. The backend holds user info, devices, public keys, and encrypted messages, while one-time prekeys are deleted post-use. Each device has its own identity key.

API keys, like for Google Maps, are restricted by sender URL to avoid abuse.

What do you think? Did I miss anything? Where can I improve? Any advice would be greatly appreciated!

3 Answers

Answered By PrivacyProtector22 On

Very promising project! Just a heads up, if you’re building it for the web, make sure to continuously audit app permissions.

Answered By TechSavvyGuru42 On

Nice setup for a weekend project! Just a couple of thoughts:
- Consider keeping public keys on the client for end-to-end encryption to reduce points of attack.
- Have you thought about token expiration and renewal? It's crucial for security.
- Also, no two-factor authentication? Might want to add that!
- Maybe switch from IndexedDB to sessionStorage for more secure handling of sensitive data. It'll clear out when the tab closes.
- A potential idea could be to wrap the client in Electron, which might help with security by preventing extensions from accessing tab content. Just some suggestions!

CuriousCactus87 -

- The public keys are for the Signal E2EE protocol.
- My idea is to have the JWT token expire with the session end. Is that feasible, or are there better approaches?
- Did not consider 2FA, great point!
- I need IndexedDB for my private keys, but I'll think about the trade-off.
- Would an Electron app work on Android/iOS?

CodeWiz123 -

Totally worth checking the feasibility of 2FA in your app. It adds an important layer of security!

Answered By FriendlyFeedback41 On

Looks solid, man! Just make sure that every message uses end-to-end encryption by default. It's also a good idea to enable two-factor authentication and keep a close eye on your app's permissions.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.