Securing my web api with JWE, doing it anynomously and other options

174 views Asked by At

I have a application containing:

  • .net core 3.1
  • Scaffolded Identitiy on Microsoft .net core
  • ef core 3.x
  • vue.js
  • net core web api

(important information: everything is in one solution on one server)

And now I am considering securing my Web Apis. This application does not have to be secure as a bank, but I want to implement a little bit more then a minimum of security.

Problem

I want to secure my APIs

What have I done

So I allready have a Authorization with the Identity. And all requests that lets user input data, I am using [Authorize] (with Idenitiy).

My questions

  1. I have read multiple places that when I have a Rest API I should use JWE-encryption. When I know that only Authorized users are able to send data, do I need JWE too? There is no sensitive information. (But all the places I have seen this, the application keeps track of the username/password)
  2. I have multiple GET-requests, that dont need any authorization. Should I use JWE there? And what userinformation should I use to encrypt it,when I dont have any information (like username/email) about the user?
  3. Are there any other ways of securing my Getcalls, so that not "everybody" are able to get/call the information? I have enabled (cors)

The three questions goes into eachother, so by separating them it would be easier to respond to the details I need help with.

1

There are 1 answers

0
Harkal On
  1. JWE is not a must have. it just adds more security to your http requests as someone might breach the request channel of a browser and can get hold of the requsts before applying SSL enryption and forwaring them to server[its possible but very difficult].
  2. it depends upon on you. if you think that the information is sensitive then you can encrpt. and for encryption always create sessions tokens and then use those tokens for request encrptions. these session tokens are independent of logged in user. session tokens ll be created for every client irrespective of logged in or not.
  3. if your apis are secure then there is no need to worry about anything. CORS just works in the browser but not in other types of clients like shell so CORS was basically designed just to stop the resources being served from unauthorised domains. it hardly saves the apis from attacker. i could generate fake 1000s of requests in a minute to your api and would crash your server. so you can limit the frequency of requests from a user within a time interval. everytime a user request update the timestamp in the sesion token [i mentioned earlier] entry in your database and where there is another requset check if the user is allowed to request the api else return error.