In my application, I am exposing a rest endpoint and configured it in twilio account for the incoming message.
Now since the request is not coming from a logged in user but from an external customer, there is no token sent in the request and so the exposed API is not secure.
Is there a way I can make it secure apart from making it a https call?
That is what x-twilio-signature should be used for. The Webhook requests from Twilio will have this HTTP Request Header. You can read more in implementation, below.
How to secure Twilio webhook URLs in Node.js
Security
Asides for what #Alan mentioned , I would also make your URL hard to guess.
https://softwareengineering.stackexchange.com/questions/325806/are-private-unguessable-urls-equivalent-to-password-based-authentication
Related
For projects that will take place in the future, it is important that my own REST server will be created. Now, I have been working on this for a few weeks, and everything concerning the REST server is ready. I can give requests and receive responses. I am just missing the security through OAuth2.
After some research, I found the authorization server from carlosHE. Now, I have everything installed in Delphi, but I do not understand how I can get the authorization workable for my REST server.
Are there people who have experience with applying the OAuth2 protocol to REST servers using carlosHE/oauth2-server? Or, maybe there are other ways that work?
Draft answer:
The client must get an access token from the OAuth2 server. (how to authenticate the client is a different question)
The access token must be stored server-side, so that the REST server can validate client REST requests.
The client then can send REST requests which contain the access token. (typically sent as a HTTP header value)
I am learning about CSRF Tokens and how they help secure your web application. I understand the basics of it, but I am confused as to how it works in practice when the web server and api are separate. In practice how is the token generated, added to the HTML and known by the API?
For example, if I host my web app on something like Nginx or S3 and serve APIs via Spring Boot, how does the HTML with the embedded token get generated and passed to the client? Would the Sprint Boot API need to generate the token and HTML and return that to the client? Is there a different flow that am I missing? If this is the case, what is the point of it being embedded in HTML at all?
All of the documentation I have read assumes you are using something like MVC or skips over this entirely.
CSRF protection is only necessary for requests made by a client (for example, a browser) that silently adds credentials for the current user, by sending a session cookie, resending username and password that were previously typed in ("Basic Authentication") or by including a client certificate. This is because users may be tricked into making unwanted such requests by visiting a malicious web page, and these unwanted requests are then made with their credentials, that is, on their behalf.
For requests made by your web server to an API endpoint, this does not apply, therefore the API endpoint need not offer CSRF protection. A web server cannot be tricked into making unwanted requests.
Or can it? Imagine that the web server offers a "proxy" endpoint that converts incoming requests into requests to the API endpoint, and that sends the API response back to the client:
Client --request--> web server --converted request--> API endpoint
Client <--converted response-- web server <--response-- API endpoint
Further imagine that, as part of the request conversion, credentials from the client are forwarded to the API. For example, a session cookie coming from the browser is converted into an Authorization: Bearer <jwt> header that is sent to the API endpoint. Then an unwanted request to the web server endpoint with credentials effectively becomes a request to the API, and a new CSRF vulnerability has appeared: this time on the web server.
The web server must then protect its own "proxy" endpoint against CSRF by issuing and validating a CSRF token.
If I have a REST API and I want to make my own authentication system is it appropriate to make an /access_token endpoint and treat it like a REST resource or should I create a seperate service for handling generation of authentication tokens etc...?
The reason I ask is this...
For a REST endpoint when you make a POST request doesn't the response want to contain a link to the resouorce so that you can GET it? What I really want to do is return the access token as part of the response of the POST request but this seems to break the paradigm of REST and would make it different from teh rest of the API, this leads me to think that the authentication should be handled by a different service.
I'll assume you're talking about the OAuth 2.0 standard, which never forces the separation between the Authorization Server and the Resource Server.
As for the other question, the access_token endpoint ought to respond to a valid POST request with a response message that contains the actual token, without this being against REST principles.
I'm currently using SendGrid's Inbound Parse Webhook to feed emails to my application. I've been able to get it working by pointing the URL to an endpoint which my application has exposed. SendGrid just sends the email in the form of a JSON format HTTP POST request to this endpoint and I just process each request internally.
My question is, now that I have it working, how do I ensure that only SendGrid can use this endpoint? At the moment, anyone can utilise this HTTP POST endpoint and pretend that an email has been sent to the application.
Can I get SendGrid to send some sort of unique key to identify themselves? Is there a way I can restrict by ip address?
There are two ways which you may secure your endpoint. SendGrid's webhooks support basic auth (e.g. https://user:pass#example.com/endpoint). You can also implement a unique key, that you check before acting upon the request (e.g. https://example.com/endpoint?key=123).
The simple answer, however, is anything that you add to the URL can act as unique authentication for SendGrid.
I need to develop a REST Web Service using ZEND Framework. I am new to this area. I would like to know how can I authenticate user's requests to my web service. Assume I am giving a token to all the people who use my web service. I can ask them to pass the token on every request. But Please suggest me if there and standard / better way to implement authentication for REST web service.
Thank you.
Prasad
I usually include the token in the http header with each request then on the server parse the header and validate the token.
X-Authorization-Token: <some hash value>
It's also completely acceptable to do as you are suggesting and require the user to send the token as part of the GET/POST/PUT/DELETE request as you would with a standard page. I have seen others put the value in a COOKIE as well.