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.
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.
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.
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.
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.
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 ;)
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.
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.
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 :)
