What is the setRequestHeader method for in pure AJAX in POST mode?

Asked

Viewed 1,911 times

1

What is the purpose and importance of this traditional method setRequestHeader pure AJAX when POST type requests are made by the client for a PHP application on the server? I am always required to use it with the value "Content-Type","application/x-www-form-urlencoded" without knowing for sure its real function. I would also like to know the security flaws already known by the community that can be caused on the server if PHP eventually receives a header with a different value than this, for me who am a layman, is a default value. Its use is mandatory?

php javascript ajax

1 answer

2


XHR().setRequestHeader serves to set a header in the request headers list. When you call it that way:

xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded")

you are setting the type of content you will assign in the request method "post" or "put", there in the first parameter of XHR().send. The type of content "application/x-www-form-urlencoded" only indicates that the content is in the format of URL parameters, for example: "?param=1&etc=2"

Headers are always used in requests, there is never a security risk for the server.

Check that one out page, it lists headers that can be set in a request. Note: not all headers can be set programmatically with the method XHR().setRequestHeader.

There is no risk of security in relationship to headers. There is no such thing as not sending headers, and besides they cannot affect the server.

For further information, there is a specification on the XMLHttpRequest here.

What can affect the server depends on your actions.

  • 1

    Practically answered the question, but with the exception of security. There are failures known by the community and how to protect the callback to receive the data sent by AJAX with a list of headers set wrong or purposely exchanged? After all, everything that comes from the users' side should always be very well checked. How to trust? Thank you =)

  • @Ingridfarabulini It is no use trying to protect the callback, you have to protect your code next to the server. With the help of the data that comes next to the client, you can easily detect some data manipulation next to the server with one condition, and with that you prevent someone from doing a certain action in a database, for example, and can respond to Javascript with some message stating that there was a failure to do such an action.

  • @Ingridfarabulini Whenever you want security to do something next to the server through Javascript already has a certain action in the URL parameters or in the posting content, do not try to expose important data and manipulation to them for the client.

  • @Ingridfarabulini Remembering: merge Strings next to the server in a PDO request, for example, SELECT..., It can be dangerous if you don’t cover/check this String because it can contain an action and be interpreted, probably, I believe that the String can be encoded, and so nothing happens (but I forgot about everything). Unfortunately it’s been a long time since I used these PHP Apis, because I didn’t need much for now, and now I forgot about the syntheses used in database requests

  • I understand your words, but I still feel insecure about this header setting. Even though I don’t know if such a security breach exists, I believe that it is the malicious person a good way to be explored, even more that basically it is on the client side that we will tell the server how the data being sent is configured, something that can easily be modified even by lay people like me and then injected codes that compromise.

  • 1

    @Ingridfarabulini Only you can give the possibility to make a code that can be easily manipulated, something that can allow someone to modify a database or server settings, modify files, etc... If you want this not to happen, you need to encode your Strings according to what they will be merged (always important in the syntax of doing an action in the database with a String, for example, INSERT...), until because there can be joined an extra action, then that’s it... if you encode a string, it will not be interpreted.

  • @Ingridfarabulini An example of encoding is using Base64, base64_encode(string), and if you want to read this string after receiving it from the database, base64_decode(string)

  • @Ingridfarabulini As always: also never let the client-side do actions that access the inside of PHP; already have actions determined through parameters.

  • 1

    @Ingridfarabulini It is important to limit certain actions with conditions, but I don’t know what kind of security problem you are having, so it is difficult to help solve it.

  • 1

    I’m not having any problems... but I don’t trust these headlines. Thank you for trying to help =)

  • 1

    @Ingridfarabulini I understand, but in fact the browser always has to send headers for a request, if they were dangerous, many sites would already have been manipulated. Headers that can be set by nodes do not cause security problems next to the server.

Show 6 more comments

Browser other questions tagged php javascript ajax

You are not signed in. Login or sign up in order to post.