For details on CSRF vulnerability see:
LabKey enforces CSRF protection on all "mutating" requests, those that change server state. These state changes can be inserts, updates, or deletes to the database, but also include changes to the file system, server session, and other persisted state. A few examples of protected mutating requests include:
All custom pages, custom actions, and API usage must use one of the approaches described below to ensure the CSRF token is conveyed with mutating requests.
CSRF tokens are verified for POST requests only, since GET requests should be read only and never mutate server state. When coding custom actions, ensure that session or database state is never changed by GET requests.
Forms that perform an HTTP POST to those actions must include the CSRF token using one of the approaches mentioned below. For example, a form could include the <labkey:csrf /> tag, which renders an <input> into the form that includes the CSRF token:
<input type=hidden name="X-LABKEY-CSRF" value="XXXX" />
The actual value is a randomly generated 32-digit hexadecimal value, associated with that user for the current HTTP session.
Alternatively, the CSRF token value can be sent as an HTTP header named "X-LABKEY-CSRF". LabKey's client APIs, including our Java and JavaScript libraries, automatically set the CSRF HTTP header to ensure that these requests are accepted. See HTTP Interface for obtaining and using the CSRF token when not using one of LabKey's client APIs.
When creating custom forms, developers may need to take steps to ensure the CSRF token is included in the POST:
Premium edition subscribers have access to additional example code and developer resources including:
previousnext |
expand allcollapse all |