# OWASP\_Application\_Security\_Verification\_Standard\_4.0 - scriptCode
## Remote service calls
**Treat any parameters entering ScriptCode as untrusted when sending them to services**
In practice, this means that the rules of the REST client API provided must be strictly followed. Among other things, it defines the way a path is created as a list of individual address segments. Such an interface seems unintuitive, but it provides greater security.
#### **Example code**
Bad:
```
const url = "/api/form/" + context.getFirstParameter("form_id") + "/data";
const response = api.rest.v1.get("host", {pathParams: url.split("/")});
```
Good:
```
const pathParams = ["api", "form", context.getFirstParameter("form_id"), "data"];
const response = api.rest.v1.get("host", {pathParams: pathParms});
```
What are we protecting against?
Proper use of the API will protect us against attacks based on modifying the target address. Let's trace the sample code, assuming that the form\_id parameter comes from a form field. If the user enters "abc/def" into the field, the "/" character will be treated as part of the address in the first example and ultimately we will call the service at "/api/form/abc/def/data", meaning that in practice we can accidentally hit a different service ("/api/form/{x}/{y}/data" instead of "/api/form/{x}/data", that is, instead of x = "abc/def", we will have x = "abc", y = "def") whereas the code from the second example will escape this character and send the request to "/api/form/abc%2Fdef/data" (that is, in the address "/api/form/{x}/data" the variable x will take the value "abc/def").
## Handling service authorization data
Authorization data should never be used directly in ScriptCode. When calling external services (e.g. through `api.rest.v1`) the platform is responsible for setting the appropriate authorization data in the request to the service. If this is not supported for a given service, a request should be raised with the PO. In the case of services for which implementation is technically impossible or will take a long time, the developers should be consulted on how to securely pass the authorization data. Regardless of the approach adopted, it is absolutely necessary to avoid storing authorization data (in code, session variables, process variables, form fields) and sending it to the frontend (form fields - including technical fields, session variables).
How can problematic data be recognized? Unfortunately, due to the variety of authentication methods, it is difficult to provide a complete list of such data - use common sense and pay special attention to data that grants access to services. Below is a short list of terms that will help you identify such data - if you encounter them, be vigilant:
* login/user and password,
* token,
* key,
* Authorization header,
* API key,
* API token,
* bearer token,
* JWT token.
## Retrieving remote resources
All resources used by us (e.g. images, documents, card images, etc.) should come from a trusted source. Most often this source is the eximee platform itself or some banking resource, but it should never be the internet. In most cases eximee limits the use of resources to trusted ones only (e.g. in the REST services client you can refer only to services defined by the administrator), however there may be places where such a restriction is not implemented (or is impossible to implement). Whenever we want to use an external source in the application (in practice, some URL), we must verify whether it is a trusted source (comes from the bank's domain, was included in the requirements) - if the source is not trusted, its use must be consulted with the PO. However, it is not acceptable to use external services to implement functionality that does not exist in the platform - in such cases a request for the given functionality should be submitted.
{% hint style="danger" %}
1. If you need to use any link in the application, make sure it is trusted and that its use follows directly from the requirements
2. If a given feature does not exist on the platform, submit a request - do not use external tools
{% endhint %}
Example problem with external resources and its consequences
On one of the printouts, we had a requirement to generate a QR code based on the application data. Since the platform did not have such functionality, the developer decided to use an external API [https://api.qrserver.com](https://api.qrserver.com/v1/create-qr-code/?data=Marcjanna%7CWarto%C5%9B%C4%87). During document generation, an external service started being called (dataFormatted was the data collected on the application), and the result of its call was placed on the printout as an image.
What are the consequences of such an action:
1. This is an external service, we do not control it, we have no influence on its downtime periods, and it may potentially disappear from the internet
2. The licensing model has not been identified - we expose our client and ourselves to legal and financial consequences of using the service in violation of the license
3. We do not know how this external service works - it may potentially generate malicious code that we place on the printout (in the PDF) and that will be executed at the client's side
4. The data in the dataFormatted variable included things such as the client's address or the amount of a cash deposit at the bank - these are data protected by the GDPR and banking law; by using them in the link, we passed them to an external entity (causing a data leak) - we expose the bank and ourselves to legal and financial consequences
## Sensitive data
**Use the sensitive logger to log sensitive data**
### **Example code**
**New loggers (preferred method):**
New loggers treat every passed parameter as sensitive data by default. To change this behavior, you must explicitly use the nonsensitive function on the parameter. Additionally, new loggers allow parameters to be placed in a text template (we do not do concatenation as with old loggers).
Bad:
```
const pesel = context.getFirstParameter("pesel");
// 1.
Logger.info("Customer's PESEL filled in on the form: {}", nonsensitive(pesel));
// 2.
Logger.info("Customer's PESEL filled in on the form: " + pesel);
```
Good:
```
const pesel = context.getFirstParameter("pesel");
Logger.info("Customer's PESEL filled in on the form: {}", pesel)
```
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/logika-biznesowa/scriptcode/dobre-praktyki-scriptcode/owasp_application_security_verification_standard_4.0-scriptcode.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.