Javascript-php Curl or a similar client request is not cross-domain, wouldn't it be unsafe? What precautions are there?

I thought PHP cURL there would be a cross-domain limit to the impersonation request.

Questions

When you design an interface, you need access to sensitive data (for example, personal data that needs to be viewed after you log in). I'll do token the testing.

But the other common interface can be directly obtained, just add the cross-domain header, to prevent cross-domain calls, but later found that through PHP cURL is able to invoke the success. eechenthe answer looked back. As follows:

The same-origin policy prevents cross-domain security in the browser. And PHP's curl can be seen as a command-line browser (client), free from any restrictions, as you use file_get_contents to download things on the internet as freely as you want, source.

Does it feel like it's a little unreasonable to design? JS AjaxThere are cross-domain restrictions, and PHP cURL in this form there are no cross-domain restrictions. Why not PHP cURL restrict the form as a cross-domain when determining cross-domain constraints?

How should such a form prevent cross-domain invocation?

Solution Solutions

1. Before you want to do NetEase cloud client, have seen 网易云音乐 the interface, is by CSRF_TOKEN preventing cross-domain calls.
   PS: Say this scenario, it seems to be able to crawl the web to get CSRF_TOKEN , and then cross-domain calls it?

2. In addition, is there any plan to solve this problem?

We look forward to your answer, thank you!

============ 10-27 15:51 ==============

Sorry, I understand wrong ... I thought it was a PHP cURL special deal. Thanks to 南小鸟 the answer, in fact, is equivalent URL to direct access to the specified, naturally will not produce cross-domain problems ...

What if I want my interface to be inaccessible to the outside world?

In the Intranet

This should not need to set anything.

External network

1. Set CSRF_TOKEN , but I looked up some csrf_token information, seemingly CSRF_TOKEN mainly to prevent 跨站请求伪造 , not to do this ... Prevent the attack by carrying your authorization information cookie:SESSIONID .

2. Check REFER .

3. Is there any other way?

At present I intend to use the JWT build Token , each time, the request needs to be brought on Token (with the user information, permission control, etc.).

Feel the pit, Sorry. Also thanks Gforce for the answer.

Reply content:

I thought PHP cURL there would be a cross-domain limit to the impersonation request.

Questions

When you design an interface, you need access to sensitive data (for example, personal data that needs to be viewed after you log in). I'll do token the testing.

But the other common interface can be directly obtained, just add the cross-domain header, to prevent cross-domain calls, but later found that through PHP cURL is able to invoke the success. eechenthe answer looked back. As follows:

The same-origin policy prevents cross-domain security in the browser. And PHP's curl can be seen as a command-line browser (client), free from any restrictions, as you use file_get_contents to download things on the internet as freely as you want, source.

Does it feel like it's a little unreasonable to design? JS AjaxThere are cross-domain restrictions, and PHP cURL in this form there are no cross-domain restrictions. Why not PHP cURL restrict the form as a cross-domain when determining cross-domain constraints?

How should such a form prevent cross-domain invocation?

Solution Solutions

1. Before you want to do NetEase cloud client, have seen 网易云音乐 the interface, is by CSRF_TOKEN preventing cross-domain calls.
   PS: Say this scenario, it seems to be able to crawl the web to get CSRF_TOKEN , and then cross-domain calls it?

2. In addition, is there any plan to solve this problem?

We look forward to your answer, thank you!

============ 10-27 15:51 ==============

Sorry, I understand wrong ... I thought it was a PHP cURL special deal. Thanks to 南小鸟 the answer, in fact, is equivalent URL to direct access to the specified, naturally will not produce cross-domain problems ...

What if I want my interface to be inaccessible to the outside world?

In the Intranet

This should not need to set anything.

External network

1. Set CSRF_TOKEN , but I looked up some csrf_token information, seemingly CSRF_TOKEN mainly to prevent 跨站请求伪造 , not to do this ... Prevent the attack by carrying your authorization information cookie:SESSIONID .

2. Check REFER .

3. Is there any other way?

At present I intend to use the JWT build Token , each time, the request needs to be brought on Token (with the user information, permission control, etc.).

Feel the pit, Sorry. Also thanks Gforce for the answer.

PHP Curl is the equivalent of opening a URL directly to your browser, which is not a cross-domain

Can be used as an interface validation, such as using JWT

