javascript - PHP cURL or similar client requests are not considered cross-domain, will they be unsafe? What precautions are in place?

Before I thought that PHP cURLsimulated requests would also have cross-domain restrictions.

Questions

When designing the interface before, sensitive data that requires permission to access (such as personal data that needs to be viewed after logging in). I will do token detection.

But other ordinary interfaces can be obtained directly, but cross-domain headers are added to prevent cross-domain calls. However, it was later discovered that the call can be successful through PHP cURL. I read eechen’s answer later. As follows:

The same-origin policy to prevent cross-domain is a security mechanism in the browser. PHP's cURL can be regarded as a browser (client) under the command line without any restrictions, just like you use file_get_contents to download things on the Internet Same as whatever you want, source.

Do you think this design is a bit unreasonable? JS Ajax has cross-domain restrictions, while PHP cURL does not have cross-domain restrictions. Why didn’t the form of PHP cURL also be used as a cross-domain restriction when determining cross-domain restrictions?

So how should such a form prevent cross-domain calls?

Solution

1. When I wanted to make a NetEase Cloud client before, I saw the interface of NetEase Cloud Music, which uses CSRF_TOKEN to prevent cross-domain calls.
   PS: Speaking of this solution, it seems that you can obtain CSRF_TOKEN by crawling the web page, and then make cross-domain calls, right?

2. Also, are there any solutions to solve this problem?

Looking forward to your answers, thank you!

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

Sorry, I misunderstood... I thought it was some special processing done by PHP cURL. Thank you Nan Xiaoniao for your answer. It is actually equivalent to directly accessing the specified URL, and naturally there will be no cross-domain problems...

What if I hope that my interface cannot be accessed by the outside world?

On the intranet

This shouldn’t require any settings.

On the external network

1. Set CSRF_TOKEN, but I checked some CSRF_TOKEN information. It seems that CSRF_TOKEN is mainly to prevent cross-site request forgery, not for this... to prevent carrying your authorization informationcookie: SESSIONID to attack.

2. CHECK REFER.

3. What else is there?

Currently, I plan to use JWT to generate Token. Each time, the request needs to bring Token (bringing user information, permission control, etc.).

I feel like I’ve left a hole, Sorry. Thanks also to Gforce for the answer.

Reply content:

Before I thought that PHP cURLsimulated requests would also have cross-domain restrictions.

Questions

When designing the interface before, sensitive data that requires permission to access (such as personal data that needs to be viewed after logging in). I will do token detection.

But other common interfaces can be obtained directly, but cross-domain headers are added to prevent cross-domain calls. However, it was later discovered that the call can be successful through PHP cURL. I read eechen’s answer later. As follows:

The same-origin policy to prevent cross-domain is a security mechanism in the browser. PHP's cURL can be regarded as a browser (client) under the command line without any restrictions, just like you use file_get_contents to download things on the Internet Same as whatever you want, source.

Do you think this design is a bit unreasonable? JS Ajax has cross-domain restrictions, while PHP cURL does not have cross-domain restrictions. Why didn’t the form of PHP cURL also be used as a cross-domain restriction when determining cross-domain restrictions?

How to prevent cross-domain calls in this form?

Solution

1. When I wanted to make a NetEase Cloud client before, I saw the interface of NetEase Cloud Music, which uses CSRF_TOKEN to prevent cross-domain calls.
   PS: Speaking of this solution, it seems that you can obtain CSRF_TOKEN by crawling the web page, and then make cross-domain calls, right?

2. Also, are there any solutions to solve this problem?

Looking forward to your answers, thank you!

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

Sorry, I misunderstood... I thought it was some special processing done by PHP cURL. Thank you Nan Xiaoniao for your answer. It is actually equivalent to directly accessing the specified URL, and naturally there will be no cross-domain problems...

What if I hope that my interface cannot be accessed by the outside world?

On the intranet

This shouldn’t require any settings.

On the external network

1. Set CSRF_TOKEN, but I checked some CSRF_TOKEN information. It seems that CSRF_TOKEN is mainly to prevent cross-site request forgery, not for this... to prevent carrying your authorization informationcookie: SESSIONID to attack.

2. CHECK REFER.

3. What else is there?

Currently, I plan to use JWT to generate Token. Every request needs to bring Token (bringing user information, permission control, etc.).

I feel like I’ve left a hole, Sorry. Thanks also to Gforce for the answer.

php curl is equivalent to opening a URL directly with your browser, which of course does not count as cross-domain

You can perform an interface verification, such as using JWT