ThingWorx REST API > Updating the Request Method and Content Type Filtering for CSRF Protection
  
Updating the Request Method and Content Type Filtering for CSRF Protection
Cross-site request forgery (CSRF) is a web-based attack that submits forged requests on behalf of an unwitting victim. If a user is currently authenticated to a site and can be tricked into submitting a malicious command, the attacker can request a state-change request using the victim’s credentials.
For more information, see the following links:
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet
A common defense against CSRF attacks is to use synchronized tokens. However, ThingWorx uses an alternate approach and instead routes all requests through a strict content type filter. This approach is equally secure while being more appropriate for a stateless implementation.
CSRF protections were added in ThingWorx 6.0. These protections might affect applications that were built prior to this release which use a custom UI to access ThingWorx via the REST API.
If your application only uses mashups built in Composer, then your application should not be affected.
If your application uses a custom UI accessing ThingWorx via the REST API, then action may be required.
Update Request Method
By default, the request method cannot be changed by request parameters. If your application was developed using these practices, you can:
Remove any code that will change a GET method to a POST method via request parameters. This is the recommended best practice approach.
Set the Allow Request Method Switch value in the Platform Subsystem configuration to true.
* 
This is not the recommended best practice, and in doing so you acknowledge you are exposing your implementation/application to the possibility of CSRF.
The Allow Request Method Switch option is deprecated and will be removed from future ThingWorx releases.
Content Type Filtering
The ContentTypeFilter has been implemented to verify that the content type in the request header is either application/json, application/xml, or text/xml for all POST, PUT, and DELETE methods. If the request is multipart/form-data, it will check for a X-XSRF-TOKEN header with a value of TWX-XSRF-TOKEN-VALUE. Requests for this multipart/form data are for file upload.
If performing file uploads, your browser must implement the FormData object.
* 
FormData is not available in older browsers (Internet Explorer 9 and below), so file upload will not work in these browsers (including entity and extension imports) when the ContentTypeFilter is included.
* 
The Filter Content-Type option can be turned off in the Platform Subsystem, but in doing so, you acknowledge you are exposing your implementation/application to the possibility of CSRF.
The Filter Content-Type option is deprecated and will be removed from future ThingWorx releases.
Best Practices for CSRF Protection
Use the following guidelines to maintain CSRF protection:
When developing new applications, all mashups built in Composer are secure. If you are using a custom UI that accesses ThingWorx through the REST API, ensure that you are not including any request that requires a method switch.
When developing new Java extensions, ensure that all new services are exposed through the ThingWorx service annotation framework. This framework is responsible for identifying, mapping, and routing all incoming requests to an implementation of a service. All services that are created and exposed using ThingWorx service annotations will be CSRF secured.
In the rare case that a new service must bypass the ThingWorx annotation framework, ensure the service only reacts to the GET, POST, PUT, or DELETE methods.
Related Links
ThingWorx REST API
ThingWorx REST Design
Updating, Deleting, and Executing Through the API