I'm creating WEB project in Angular4 and Spring. This is educational project for my learning.

I want to encrypt some data in Angular and then store it in backend. Idea is to not have any acces to user data in backend - user will be more sure that his data is not sended to server, it is not possible to steal it, sell it etc.

How can I make this site secure? Good encryption in Angular before sending to DB is basic, but what else? Some kind of RAM encryption to secure frontend? Some kind of frontend isolation? Any extra security from backend? What else can be done?

I think my main concern is if anyone can acces RAM and see users password stored - enven if I clear it as soon as possible. I'm asking about your general thoughts in this security area.

I'll write a little more about idea. There will be possibility to put some sensitive data in frontend. And then frontend is encrypting it (using users password) and sending to backend. So, I'm a little afraid about this user password which need to be clear text in browser memory - at least during encryption in Angular.

2 Answers 2


[AngularJS] Common Pitfalls

AngularJS makes it very easy for developers to get in to some dangerous territory. Here's some common things that I see when I assess websites using AngularJS, regardless of the backend:

  • Lack of server-side session validation
  • Lack of server-side input validation
  • Decoupling the frontend from the backend and forgetting things like output encoding

Lack of server-side session validation

The near-universal pitfall I see is that the frontend handles all of the session checking and routing, but I can just call the backend endpoints and be anybody I want to be. AngularJS also has this cookie thing it does with defining the user permissions in the cookie. Don't do that. I can manipulate that cookie and send it to the server.

To avoid this, do your session checks server-side.

Lack of server-side input validation

Another common pitfall I see is that AngularJS gives a lot of nice tools to developers to do things like routing, input validation, all in a nice, rich UI. However, those input validations aren't done server-side.

To avoid this, enforce validation checks on both sides.

Decoupling frontend and backend

As mentioned, AngularJS gives nice things to developers. However, when the backend and frontend are decoupled for things like UI generation, routing, it is easy for developers to forget where the data is coming from and forget to properly output encode. AngularJS does do some things to help you, and newer versions target output encoding specifically, but ensure that you do it correctly.

[Spring] Common Pitfalls

For the most part, the advice I give is independent of any framework chosen. However, the backend is much larger, and I could write a book. So instead, I'll try to limit it a bit, especially given the question.

  • Ensure the framework is properly configured. Frameworks like Spring come with out-of-the-box with developer-friendly tools. In the case of Spring, be sure to read up on the production-ready endpoints, for example.

  • Maintain your patches. No framework is without bugs, and Spring is no exception, having experienced significant security vulnerabilities in the past. Keep your pom/gradle versions up-to-date and you'll be fine.

  • Review deployment practices. While this is probably starting to get outside the bounds of your question, I want to bring it up because it is part of the learning process.


With that all said, now the encryption. Unless you are doing something where the user should be the only one with knowledge of the key, doing encryption in JavaScript is highly discourage.

With user passwords specifically, industry standard, and recommended approach, is TLS. Anybody between the browser and your server will not see or be able to manipulate the data. TLS certificates are free these days, so there's really no good reason not to if it is on the internet. Without knowledge of what kind of data you want to encrypt, I can only give you some common pitfalls of doing something like this in the browser:

  • Key generation, expiry, storage, and revocation
  • Ciphertext storage
  • Encryption algorithm


Putting aside for the moment your explanation of wanting to use the user password, encryption requires key management. You need to handle generation, storage, expiry, and revocation. This means that you need to have sufficient entropy to generate the key, decide how to handle the key once it is generated, how to handle the key when it approaches expiry and once it has expired, and when the user decides they want to change their key.

In your case, this actually becomes a little more difficult, because now you have to build functionality that'll rotate the keys when they change their password. Otherwise they'll lose access to their old data.

Ciphertext storage

Now that you have the key management, how and where do you store the ciphertext? This becomes a question that matters more for the data you want to encrypt.

Encryption algorithm

Inevitably, you'll need to chose how you want to encrypt the data. Do you use symmetric or asymmetric keys (your stated use case is symmetric)? Now you need to choose algorithm and mode of operation. And randomly generating an IV.


Engineering a solution that can handle encryption on the frontend safely is hard. Really hard. A lot more difficult than handling it on the backend. There are legitimate reasons for doing the encryption on the frontend, but since this is a learning project, I'd encourage you to start on the backend and then work towards the frontend.

There's a lot in this area that I haven't covered and can't cover here for space reasons, and without knowing much more about your objective. In my professional line of work, questions I'd typically start with include:

  • What data are you trying to protect?
  • Who are you trying to protect it from?
  • Are you prepared to handle the unique difficulties on the frontend?

This isn't to discourage you, as there are legitimate reasons for doing this encryption on the frontend. But it is hard to get right, and using the user's password has additional complexities that need to be solved for, some of which I mentioned above.

  • I'll write in Angular 4. I don''t know if what you paste fits it? @Encryption - there is reason why I want to ecrypt it in browser even if I use TLS. I don't want to have users bassword in backend. Use must see it in frontend code (if he want's check it). Commented Nov 22, 2017 at 10:24
  • Remember that anything client-side can be tampered with without advanced knowledge. Everything must be validated server-side. Client-side validations are nice for usability, bandwidth usage reduction etc but have no security value
    – niilzon
    Commented Nov 22, 2017 at 11:01
  • I don't want to vaidate on client side. I want to encrypt/decrypt on client side. I know, easier is to do that on server side but concept of this project is that server can not decrypt data - only user. So that is why I wanted to discuse this scenario. It is not easy challange, but I think it is possible to do or at leas interesting for discussion :-) Commented Nov 22, 2017 at 15:19
  • I misread the previous comment. Since you want to have a zero-knowledge, there are a host of issues to consider that I can't address here. I'd suggest reading up on zero-knowledge encryption @RysicRychu
    – h4ckNinja
    Commented Nov 22, 2017 at 22:01
  • 1
    This is an extremely thorough and excellent answer.
    – joe
    Commented Nov 23, 2017 at 0:46

Aside from encryption, the best way to secure backend data/user data is to enforce input validation that prevents a malicious attacker from accessing valuable resources. Restrict malicious input via whitelist/blacklist and sanitization.

See OWASP input validation cheat sheet here : https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet

Hope this information is helpful!

  • Thank you! And what about frontend? For my project it is more critical because there will be sensitive data - backend should just store encrypted data sended by frontend. Commented Nov 21, 2017 at 15:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .