I'm building a service that provide some readonly information that is going to be used in multiples websites, some with login and some public.
I dont want to make the api public to any website so I'm not sure what auth method i should use. I have some ideas but I don't want to reinvent the wheel.
I was thinking on have the backend of this sites request a token to my server using a secret/password/private_key then they should pass this token to their front end and pass it with each request to my server(their front end will comunicate directly with my API)
If your public non-authenticated API is accessible by your site, there's no way to stop other people from consuming this API and stealing your data.
You can stop other websites from directly taking data from your API (by not using CORS headers), but if your website is showing data from your API publicly, then assume anyone else can.
If your business relies on not being possible, rethink your business model. If data appears on the screen of a random user, it means that user can take that data and put it somewhere else. It's how the web works.
I totally agree with #Evert. Having said that, there are some ways you can use to make public API accessible to some and not to all. It will not be perfect, and using some kind of API tokens will be a better solution most of the time, but it might suit your needs.
First of all you can use firewall rules and allow connections from certain IPs only. Simple and will work as long as the source IPs do not change.
Another idea you can use: look at youtube and how private videos work. There is a secret in the URL. With enough entropy you can build publicly accessible URLs this way which can be used to share a simple link with friends, but will be hard to guess by others. There are drawbacks to this technique. You may only allow people to share their content this way, as they have always the rights to make the link public by pasting it into their tweeter/yt/other.
Related
I am currently learning to make DRF APIs for something I am working on. I was wondering how exactly I would secure the API POST requests I send via the client side?
For example, let's say I have a log in form where the user can enter their information, this information needs to be send to (or POST-ed to) my API for verification. I do not want just anyone sending requests to the server and so, I would want to use an API key but since this is being done on a website, anyone could see the API key if they wanted to, and then exploit the server by sending a ton of requests.
My current idea is to use serializes in DRF to check if the API POST request has everything it needs but I am fairly certain this can be easily found by checking what sort of JSON my code sends to the server, so how exactly do I go about securing this such that I can send the information to the bare domain (like http://127.0.0.1:8000) and then have code which can accept that information?
I apologize for any confusion, if it is confusing. Let me know if you need any clarification.
If you are creating API any one can send request to server. same goes for website and webpage. Their is no way you can avoid this. But their are ways to handle possible misuse.
like using CAPTCHA for login form which can be filled by one on the web. though wrong CAPTCHA text can be send by anyone you must check it on server for their correctness. or use google reCAPTCHA like services for outsourcing this task.
API key should be given after login NOT before login. and if it is given after successful login then the key is obtained by legitimate user which can obviously do whatever he is allowed to do on website. their should not be problem in that.
further explanation to the question will lead to details of denial-of-service i.e DOS attack. you should consult expert on that field if your application requires to handle DOS attack.
I am doing a Fullstack Web Project at the moment and am now looking into API security. I have implemented a user login which then allows the client to access most routes of my API. But there are unprotected routes as well which can and must be accessed without a login (e.g. sign up, login, ...).
One route for example returns whether a specific username or e-mail-adress is already taken by another user and is used during the sign up process. For someone with bad intentions this public route would be a great help to figure out which e-mail-addresses or usernames to try to hack or guess the password for because they can avoid credentials that aren‘t in use.
I know that this functionality is used very often by big companies to show the user whether he can use his desired username or not. How are they making sure there‘s no abuse? How can I protect my API and users from that?
I would appreciate any kind of help. Thanks a lot!
To limit API abuse rate limiting is a good practice. One way is to specify a maximum amount of API requests per IP address and after that ignore the requests.
A good article describing solutions to do so and also showing examples for an implementation in NodeJS can be found here.
Thanks to Gilbert Le Blanc for the help on this one.
I'm using web api for my application on ASP.NET CORE
If someone see application soruce code, there is a backend url, isn't it?
Then, that guy can use my api if he succeed my application decompile
How protect that situation
I'm just stutdent, so... Just my curiosity
Authenticate your API
If you plan on having a private API (not open to everyone), then you should force users to authenticate themselves by using an API access token. Each token should be specific to a particular user, and there should be consequences for distributing a private key (such as revoking it and blocking the person associated with it) or else people will just share them without care. This will allow users to communicate with your server and run commands or queries as they please. Assuming you have written these functions correctly, they shouldn't allow an attacker to access much beyond his given scope of given API functions (which should be queries at most).
Document, document, document!
You shouldn't allow users access to your source code for this. You should document your API thoroughly regarding details which methods the user can use, what sort of data it expects to receive, and what sort of data you will get back from it (including all errors, possible problems with the users request, and how to fix their requests). Make sure you heavily test these too, and make sure that you can't perform any sort of malicious actions with your API. It's also a good idea to give your documentation to another person and ask them to read it. If you've missed something important, you will know afterwards because there will be a clear gap in their knowledge of the API.
What, not how
Users should know what a function should do, but not how it does it. For example, I could use /api/GetUserById. I should know that I can get a user - I shouldn't know how it gets the user. The only thing I need to know is that I perform this call and I get back a json object with details about the user. That is it.
As with any of my posts, if there's something I've missed or something you need further clarification on, please let me know in the comments and I'd be happy to explain further. I hope this helps
First of all i wanna apoligise for my bad english, iam from holland.
For an school internship i read the last days a lot about API's and watched a lot of video's. But the security options are not clear for me. I read somethin about Oauth, saml and openID but i dont know which i can use in my situation.
This is the situation i will create. i need to add 2 security's. one for the private(internal) side and one for the public side.
Private(internal) side
For the private side i cant find any solution. I think i can use oauth for it . but i cant find which flows there are and also webflow) dont know which flow i need to use. This one is what i mean (youtube) i also read topics on stackoverflow but i cant find a clear answer on this question.
The backend on the private side wil never change and there wil never be more api gateways or backends on the private side. No-one need to be acces to the backend, only the API gateway.
Public side
On the public side there are a lot kinds of clients but they dont need to login with credentials. I only wanna know which application uses our API and how many connections they make. I will be able to disable the acces from one client. Also here i came out by oauth. but the flow i found works witch user credentials but i don't need to identify each infividualy user.
Can some help me to find a good or best practice security method for my situation?
You don't have to care about OAuth. It is enough to (1) issue a pair of API key and API secret (= API credentials) to each client application and (2) require that API calls to your Web APIs come along with API credentials.
OAuth is required only when your web service has end-users and you want to allow third-party client applications to access the end-users' data with restricted privileges.
I want to write a google chrome extension, that should make a request to my website to send and get some data, so, actually I should do an ajax request like it is written here https://developer.chrome.com/extensions/xhr.html
var xhr = new XMLHttpRequest();
xhr.open("GET", "http://api.example.com/data.json", true);
I wanted ask if there is a way to somehow secure the code or prevent others from using my api, because actually the other users can see the source code of the extension when they install it and so use my api without me being aware of it.
EDIT:
If I need to make some sort of authentication, than how can I authenticate the user before making the ajax call ? for authentication I will need to send a request to my server , but for that I should send , e.g. username and password, that should be saved somewhere in the extension's files, which, in fact, can be seen by the users, when they install the extension.
Thanks
Don't trust the browser, take steps to authenticate the user instead. So, in this case, you could require that YOU enter in a password that is used to communicate with your server.
Your Google extension would simple require you to enter in a password before it attempts to use AJAX to communicate with your server.
Be aware that you should build in means of protecting yourself from brute-force attacks. So, do things like lock everything down if there are more than some small number of wrong passwords, etc.
You could also consider using the password to simply decrypt the destination of the XHR, but if you go this route, you should store this very carefully, because this will be brute-forceable offline.
EDIT
Trying to lock down an API so that only a single application can use it is just not practical nor technically possible, so you're only hope of doing this is to authenticate the user using the API, regardless of the accessing software he is using. You could have the user sign an agreement that legally limits them to only your extension, but I suspect this will go largely unenforceable and will consume your time tracking abusers down.
If you don't want unauthorized people even knowing where the API is, you could perform authentication using an out-of-band mechanism: over the telephone, email, SMS, or simply, another API that will grant the user a password or token that requests to your API must be accompanied with.
During this out-of-band process, you could also grant the user, a unique URI (the API access point) that is only valid per authenticated session (https://api.totally-cool-extension.com/api/ijyeDvB5dYvSiWG97OLuTAoNWwbhuZ0/, for example). Any requests to your server on OTHER URIs simply won't work. However, this isn't theoretically much different than using the same API access point, and having a good password. It just changes the number of places in your architecture that will be performing authentication and/or authorization checks.
<aside>My vote would be to reduce the number of authorization/authentication points to as few as possible so that you can spend more time on getting that one place correct rather than having multiple places and possibly multiple logic flaws or other things that could lead to vulnerabilities.</aside>
You could also explore using Public Key Infrastructure and/or one-time passwords schemes or device-based token generators, etc., but in the end, you'll be allowing authenticated and authorized users to use your API. And, thanks to the Internet, this will not remain an undisclosed URI for long.
And, more importantly, it will not prevent someone from using the data on their own. Even with all these measures in place, it would be trivial for an authorized user to collect this data as it is being streamed to your extension. Or, if you employ point-to-point encryption, they could screen-scrap or use some form of JS introspection on your very code or even extract the data from their computer's memory.
I know you were looking for a silver bullet here, but it doesn't exist.
I think you are doing it wrong. You should never trust what's going on on internet users PC's. Never!
Move the line of trust one step inward, make your API public and then design the security where you have perfect control - server side.
I could not get correct aspect of your use case
Few Points:
Your extension code is always traceable( Any one who has installed extension can view the code)
If you are looking for security through complicated or obfuscated coding patterns you end up slow down of understanding process not the whole.
If your target is to ensure users who install your extension should be able to access and inert all other users( Who have gained illegal access or downloaded and edited code) have a session shared key per installation.
Please explain further use case so i can help you better.