这取决于问题中没有提到的多个因素。
第一个问题是认证在服务中是如何工作的。如果它是客户端浏览器不会自动发送的东西（例如，不是基于cookie的，而是添加到请求头中的令牌），那么服务就不会受到CSRF的攻击，您可以关闭csrf保护。
如果它使用Cookie（大多数情况下可能不是最适合服务的），那么你需要保护它免受CSRF的攻击。至于如何保护，这取决于实现了什么样的保护。如果是标准的同步器令牌模式，那么你需要首先通过GET下载一个页面，提取令牌，然后在后续的POST/PUT/DELETE请求中将其发送回相应的字段。这在移动的应用中看起来很尴尬，您最好将API更改为基于令牌的身份验证。：）如果是类似于双重发布的情况，您可能能够创建一个服务中接受的双重发布令牌。如果是其他情况，您需要了解保护是如何工作的，并找出如何将正确的内容传递给服务。
顺便说一句，可能容易受到CSRF攻击的不仅仅是基于Cookie的身份验证，例如，如果API使用HTTP基本身份验证，那么浏览器也会缓存并自动发送该身份验证，因此，如果用户直接在浏览器中输入凭据，它就容易受到CSRF的攻击（但这是一个奇怪的用例，可以降低风险）。此外，客户端证书是由浏览器自动发送的，同样容易受到CSRF的攻击。
所以总结一下（稍微简化一下，详见上文）：

• 服务的身份验证是否基于Cookie？
• 否-〉移除CSRF保护，它不容易受到攻击（但请参阅上面的例外），完成。
• 是-〉2.
• 是否可以将身份验证更改为基于令牌的身份验证（令牌在请求头中发送）？
• 是的-〉更改它，完成。
• 否-〉3.
• CSRF保护的方法是什么？
• 同步器令牌模式-〉您需要获得一个页面来获取要使用的令牌
• 双重发布-〉取决于实现，您可以在cookie和头中双重发布适当的值
• 其他内容-〉了解保护的工作原理以及如何发送正确的令牌

还要注意，如果在服务上启用了CORS（移动的应用程序不需要），这会使CSRF方面的事情变得有点复杂，但这是一个正交问题。