Amber, especially its offline APK, is likely more secure against session hijacking than nsec app. As a native Android app with offline capability, it sidesteps many network-based vulnerabilities. Nsec app, being web-based, is potentially more exposed to session hijacking risks.

I assume basics are being followed like:

- Using HTTPS to encrypt communication and prevent sniffing.
- Implementing proper session management, including secure session ID generation and handling.
- Using additional security measures like IP binding or user agent checking.
- Regularly expiring and regenerating session IDs

That said, we'd need to hear directly from the devs about specific safeguards. Even then, the only way to know definitively if the implementation is solid is through a successful exploit, or a thorough independent security audit. 

Security audits are expensive and basically everything built on and for Nostr is still in beta, but like password managers, security audits are ultimately necessary for greater trust and certainty especially with everything that gets attached to a user's npub, and to my knowledge, neither has undergone or passed such an audit yet.

I personally use Amber for its offline capabilities and potential security advantages. However, always download from trusted sources and stay cautious, especially on shared networks.

nostr:nprofile1qqs827g8dkd07zjvlhh60csytujgd3l9mz7x807xk3fewge7rwlukxgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz7qgswaehxw309ahx7um5wghx6mmd9usjfpck

nostr:nprofile1qqsrx4k7vxeev3unrn5ty9qt9w4cxlsgzrqw752mh6fduqjgqs9chhgppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg6waehxw309aex2mrp0yh8x6rfw3nx7unrv5hx7mn99uslkdah

Any input on this would be appreciated. Thank you. 

 I'm not sure what is meant by cache hijacking. 

Re. session hijacking we might be talking about at least two things:
- vulnerability inside nsec.app such that someone gets access to your "session" in nsec.app
- vulnerability inside nostr app connected to nsec.app that exposes the app's session/connection info so that hackers can access keys on behalf of the app

The first part doesn't have much surface with nsec.app - we only use server to store encrypted keys and to subscribe to notifications for the signer to wake up. There's basically no "session". And any server-side auth is based on nip-98 which requires a new token signed by your nostr keys for every request, so again there's no "session" - you can only sign those tokens if you steal the main key. 

The second part doesn't depend on the signer (online or offline) - no matter which signer you use, it's the app that's connected to the signer that needs to be hardened against session hijacking. That's why it's super-important to not give excessive permissions to any (even trusted) app in your signer, so that potential hackers' access to keys was as limited as possible. Also when connection is established using bunker-url or nostrconnect url we use a one-time "secret" so make sure the connection can't be spoofed and url can't be reused.

I'm not a security specialist, and I agree that a formal security audit would be beneficial. We'll get there eventually.  

 Just to complete what brugeman said here.

When connecting with nip 46 there's a chance someone can pretend its the application you are trying to connect, but for this attack the attacker needs to know your relays and guess when you are connecting to an application 
To mitigate this there's a use secret option, in amber it's off by default because at the time most applications didn't supported this

For native applications using nip 55 I use the package Id of the app so if someone wants to pretend it's an application like amethyst they can't, the only way to do this is making you uninstall amethyst and install the fake app.

I'm also not a security expert so it would be better if we had an audit 

 Thank you for your response - very insightful.  💯 It confirms my initial thoughts — much appreciated your time. 👌👏