This was going to be a comment, but it's going to be the closest thing to an answer you're likely to get for a question like this: learn to threat model.
Start by documenting a system design. Not a final design, just one that will do what you want. Decompose the design into components and principals (actors). Determine and specify every data and/or execution flow. Once you know what a trust boundary is, figure out where they are (or should be) in your design.
Then comes the central aspect of threat modeling. For every component, and every flow that crosses a trust boundary, figure out what the relevant threats are. There might be a lot of them, and you might well not know what's even possible for a given component or type of flow (does TLS provide non-repudiation? is AES-256-GCM vulnerable to padding oracle attacks?); it's going to take a lot of research. For each threat, determine whether it's a real concern (lots of things that are technically threats are just out of scope, like "there's a massive outbreak of nuclear war"). For the "real" threats, figure out if you can realistically fully mitigate it, and write that mitigation into the design. Make sure it doesn't open you to new unmitigated threats, like adding slow password hashing putting you at risk of denial of service, or using a third-party library opening you to supply chain attacks. For the threats that are hard to fully mitigate, figure out the severity (impact and likelihood) of each (you can optionally do this earlier), and whether they represent too great a threat for you to accept. If they do, and you still don't have a workable mitigation (going to need a lot of research here too; do you know what you can do with seccomp, the guarantees of the samesite cookie flag, or the difference between webviews/embedded browsers/separate browser apps?), then take a step back and ask what about your entire design would need to be different such that the threat wouldn't exist. Sometimes it's simple, like moving a particular check to the server instead of the client. Sometimes it's tricky but somebody has figured it out, like ratcheting algorithms a la Signal. Sometimes it's just not practically possible to prevent a threat, either because it's too difficult (no, you probably can't formally prove every algorithm in your code) or because it's not possible even in theory (there just is not any such thing as perfect DRM). If you run into one of those, you have to decide: ditch the whole idea, or accept a partial mitigation (assuming you can find one of those) that leaves some lesser, acceptable level of risk.
And hey, once you can do that for an arbitrary system composed of web, mobile, and desktop components, you're set for life on employable skills! Competent security engineers who can analyze a system, find its weaknesses and assess their severity, figure out how to solve or at least partially mitigate the ones that matter, and do it all while meeting the original product/feature objectives and accounting for the practical limitations (development time, server resources, being acceptable UX for the target userbase, etc.)... that's a very in-demand skillset!
Then you can branch out from there and learn how to actually verify the implementation of that design, through code review and penetration testing...