-1

I have a React/Express application, I want to fully secure it. I'm looking for best practices for these features:

  • data encryption/decryption
  • end-to-end communication
  • access control
  • role management
  • authentication
  • threat detection
  • file protection
  • session expiration control

If I missed something please mention it.

4
  • 1
    This is waaaaay too broad a question. "Fully secure" is impossible in practice, and even if it weren't, you need to hire a security engineer and get them to work through all your design docs, and then implementations, not give a high-level overview of your tech stack and expect people on the Internet to infer everything you might do wrong. Or write up a brain dump of the sum total of relevant application security knowledge, for that matter.
    – CBHacking
    Mar 18 at 13:40
  • it's about learning and how to design secure apps more than programming, for that i asked about best practice not exactly a tech Mar 18 at 13:51
  • 2
    You say "fully secure", that's going to take a lot more than best practices to even get close. Also, we still don't know nearly enough to answer. Best practices for what? A real-time multiplayer game is very different from an ecommerce storefront is very different from a secure chat client is very different from a malware analysis tool is very different from a graphing calculator is very different from a Google Docs clone. Besides, even if we know what we're giving best practices for, and even if it's at all reasonable to ask for all of them, that's not enough. Everything has its own threats.
    – CBHacking
    Mar 18 at 14:24
  • "I want to be the healthiest person. How do I do that? I want to know how to survive cancer, car crashes, stubbed toes, genetic disorders, and falling pianos. And anything else you can think of." -- that's far too broad a question to answer. And so is this.
    – schroeder
    Mar 19 at 12:30

1 Answer 1

3

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...

Not the answer you're looking for? Browse other questions tagged or ask your own question.