When developing automated Cypress front-end testing, I have allowed local static IPs to bypass Cloudflare's bot detection in their WAF. Though, this is not the most sustainable solution. I have thought using HTTP request header fields filter in Cloudflare and then adding some header to each Cypress test, but not sure does that follow the best practices either.
Related
I am creating an API that would serve data to my frontend app. The API is on api.myapp.com and the app on www.myapp.com (same domain, just another subdomain). They communicate with AJAX requests and CORS is all set up, working fine.
But I have another app on another domain (www.myotherapp.com) which partialy uses the same data as myapp, so I was thinking of reusing the API so myotherapp could requests data from it too.
I think it is one use case of API, to be reusable, right?
But then, there is something that I may have missed, because as my API has CORS enabled with "Access-Control-Allow-Origin: www.myapp.com", it won't allow other apps to use its endpoints, right? Their AJAX requests would fail with CORS policies.
So how are public API built and configured? How should I set my API so it can serve several apps (ideally, only the ones I allow)?
Thanks for the explanations :)
There is an Origin header in the request and your API should check if this header is one of the allowed. If it is, then return it as an Access-Control-Allow-Origin header.
If the API is public, it can returns * as Access-Control-Allow-Origin header.
I want to make a request to verify people's ID using laravel. Since it's very credential, I want to make it available only if they verify it from their mobiles.
So it must be prevented that the IDs are verified from postman request.
Is there a way to detect that a request is sent from postman or not?
Any idea would be very appreaciated :).
Thank you before
Postman has a tendency to send a header called something like postman-token so you could block the request if such a header exists.
Edit Note that this header can be turned off in postman settingss
As #EdwardChew wrote, this does NOT prevent people from using postman/curl/python/anything else. adding authentication to the endpoint is the best approach.
Sample postman request:
GET /api/car HTTP/1.1
Host: localhost:8080
Content-Type: application/json
cache-control: no-cache
Postman-Token: 05f5c492-3697-41b1-be0f-fb9bc4499b96
Since postman has the "code" feature, if the request is blocked it is simple to copy it as a curl command:
curl -X GET \
http://localhost:8080/api/car \
-H 'Content-Type: application/json' \
-H 'Postman-Token: e37790ea-a3a5-40cf-ac4c-b80184801f94' \
-H 'cache-control: no-cache'
and just deleting the line with the Postman-Token header. I normally do so when experimenting with APIs.
If you look at the Laravel doucmentation, there is a section on authorization: https://laravel.com/docs/5.8/api-authentication
which would force users to add a header token something like this: Authorization: Bearer 8fyew8f9yefo7o9yg98gyr and you would then be able to verify the caller
So it must be prevented that the IDs are verified from postman request.
Is there a way to detect that a request is sent from postman or not?
Checking that it comes from Postman is easy for requests sent from Postman where the boxes are checked for Postman-Token and/or User-Agent:
So you would add a check for them in your backend, but then the attacker would not send the Postman-Token header and for the User-Agent we will just send exactly the same one your mobile app/browser sends, thus easily bypassing your checks. By the way Postman is not the only tool, others exist like Insomnia, and then you also need to remember that requests may also come from a Proxy like mitmproxy, burp, zap, charlie, and many others. Do you get the point... it's not feasible to rely on headers to identify what is doing the request.
I highlighted the word what because who is in the request for your API backend is not the same as what is doing it.
The Difference Between WHO and WHAT is Accessing the API Server
In an article I wrote, entitled Why Does Your Mobile App Need An Api Key? you can read more about the difference between who and what is accessing your API server, but i will I quote the following from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
So the who is the user of your API server that you will be able to Authenticate and Authorize access to the data, and the what is the software making that request in behalf of the user, your genuine web/mobile app, a tampered one, an automated script or someone manually poking around with your API via cURL, Postman or other similar tools.
By now I hope that you have enough knowledge to understand why the user(who) authentication is not the same as app(what) authentication/attestation.
POSSIBLE SOLUTIONS
I want to make a request to verify people's ID using laravel. Since it's very credential, I want to make it available only if they verify it from their mobiles.
It's not clear if you mean from a mobile browser or mobile app, but I will provide possible solutions for both.
For Mobile Apps
To learn how you can lock your API server to your mobile app I recommend you to read my answer to the question How to secure an API REST for mobile app? for the sections on Securing the API Server and A Possible Better Solution.
For web apps
Due to the nature of how the web was built, all you need is to hit F12 or inspect the page source, and then search for whatever you need to access the API server from another tool.
To learn some useful techniques to try that your API server only responds to requests coming from What you expect, your genuine web app, I invite you to read my answer to the question Secure api data from calls out of the app, specially the section dedicated to Defending the API Server.
DO YOU WANT TO GO THE EXTRA MILE?
I don't know if you already read some of the OWASP resources I am about to link, but in any response for a security question I like to reference the amazing work from the OWASP foundation ;)
For Web Apps
OWASP Web Top 10 Risks
The OWASP Top 10 is a powerful awareness document for web application security. It represents a broad consensus about the most critical security risks to web applications. Project members include a variety of security experts from around the world who have shared their expertise to produce this list.
The Web Security Testing Guide:
The OWASP Web Security Testing Guide includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
I think instead of detecting whether the request comes from Postman, it is better for you to protect the endpoint with authentication.
With this, even tho the user submitted a request through postman, you can still make sure that it is the user itself who made the request.
Please do let me know if there are actually other concerns bothering you. Cheers :)
Using the following stack:
AWS amplify
NodeJS
ReactJS (built using create-react-app)
When running amplify mock it automatically assigns an endpoint with HTTP (as can be seen in the terminal and the aws-exports.js file).
I am however hosting my app locally in an HTTPS environment using ($env:HTTPS="true") -and (npm start) so as to better accommodate the social sign-ins which usually require all requests to come from HTTPS even if on localhost.
I constantly have to change my env to HTTP to try out things with the mock backend instead of just maintaining everything in HTTPS.
Is there a way to let the mock backend be served over HTTPS?
I have found a partial answer.
using the chrome browser settings, select privacy and security and go to site settings.
Add the URLS you are requesting over http into the insecure content allowable section. This allows an origin of https to request over http.
I am working with a project in which I have to send data from arduino using http post request to my web rest api. I know web browsers do not allow cross domain requests. So here do I have to take care of same origin policy or not? If yes then while testing my api I use fiddler , so is not it cross domain?
If the client making the request isn’t running in a browser, the same-origin policy doesn’t apply.
The “origin” concept and the notion of same-origin are in practice really only relevant to web apps running in browsers. Browsers are the only runtimes that enforce the same-origin policy. Runtimes other than browsers can all freely make cross-origin requests without restrictions.
So unless the client code you’re sending data from on the Arduino is running in a browser, you don’t need to worry about any cross-origin restrictions prevent you from doing anything.
Maybe I'm just not understanding this right, but this doesn't seem to make sense to me.
I have an MVC4 project exposing an ASP.NET WebApi. It works great making calls to the API within that project, but obviously making calls to it from another running project (on another port) requires cross-site scripting.
But here's my question: Doesn't this defeat the purpose of an API? If I want to make calls to the reddit API from my site, the fact that this is considered cross-site scripting makes it not only a bad security practice, but in some cases impossible.
If XSS is required to do this, doesn't that make AJAX pretty useless as a whole?
Simple answer: Of course not!! Pretty much the whole of the modern web is built on AJAX, if it was so pointless it would never have gone from a MS proprietary API to being the backbone of web 2.0 and all that has come since.
Complex answer: Firstly, XSS is a form of attack/vulnerability, not a form of request. What you're referring to is the same-origin policy, which limits AJAX requests to the same domain, for security reasons.
JSONP is typically used to make async requests to third party APIs. Your own API will typically sit on the same domain as your website so you will not have problems. If your API must be on another domain, you can either look at CORS or setup of a transparent reverse proxy to forward your requests to another server.
Hopefully this all makes sense, it'll at least give you a good foundation of knowledge to build from.
Traditionally, most apps have had both a server and a client component. The server component would do all the heavy lifting, including making requests to other APIs. Since the API request is done server-side, the request could go to any remote API server. There was never any thought given to accessing APIs from the client, since people expected the server to do it.
In recent years, we've seen more and more functionality pushed from the server onto the client, specifically through JavaScript. But making remote requests is one of the things that couldn't move to the client, due to browser's same-origin policy. So its not that the purpose of the API is defeated, its that we are now using APIs in ways we didn't conceive of before.
It would be irresponsible for browsers to suddenly ignore the same-origin policy. This would break the thousands of sites out there who depend on same-origin policies for security. So instead, the W3C has proposed the Cross-Origin Resource Sharing (CORS) spec. The CORS spec allows requests to be made across domains, but does so securely by letting the the server have the final say in who can access the API. This makes cross-domain requests possible, without breaking existing APIs.