# APEX Safety Good Practices

APEX uses the best of modern web technologies to create native web applications. Unfortunately, this also introduces modern vulnerabilities that we need to be aware of. To protect applications, APEX has several built-in security features to prevent SQL Injection and Cross-Site Scripting.

Often, important processes in our applications are triggered when a button is clicked. For UI reasons, if a process can’t be triggered, or users don’t have permission, the button may become inactive or disabled. However, this is only HTML. If the application process is not secure, someone with basic HTML knowledge can re-enable this button and trigger your process!

Let’s first see what is behind a disabled button. If we inspect this button using the Chrome console (right-click on the button and select “inspect”), something similar to the code below will show up:

```xml
<div class="t-ButtonRegion-buttons">
    <button onclick ​="apex.confirm('Are you sure you want to place this order?','PLACE_ORDER');" 
    class="t-Button t-Button--hot lto6341306998453375987_0 apex_disabled" type="button" id="SAVE" disabled="">
    <span class="t-Button-label">Complete Order</span></button>
</div>
```

If we remove the property *disabled=””* and the class *apex\_disabled*, the button becomes active and clickable again.

So, should I hide the button?

In some cases, it could work, but if you have just an application process on the page that fires when you submit the page, someone can easily call it by using just the JavaScript below:

![No alt text provided for this image](https://media.licdn.com/dms/image/C4D12AQGe8oVUp9i28Q/article-inline_image-shrink_1000_1488/0/1555499618112?e=1721865600&v=beta&t=xywopgu_vmc6ONVv5FCCWIVPXbWpR3f4ho_6CH39oHU align="left")

Therefore, what if I hide the button and add a Server-side Condition in the application process to only fire when the SAVE button is clicked?

![No alt text provided for this image](https://media.licdn.com/dms/image/C4D12AQFs8GKHwkJVYw/article-inline_image-shrink_1000_1488/0/1555499655009?e=1721865600&v=beta&t=9qqZq3Ql-40eQJJjvGVs8M4pF0p94oMRsG5Ytt-jV4w align="left")

Let’s look again to the button HTML [above.*id*](http://above.id)*\=”SAVE”*, the condition: “only fire when the SAVE button is clicked” means the same as “request = ‘SAVE’”. The would-be hacker just needs to add the request to the JavaScript.

![No alt text provided for this image](https://media.licdn.com/dms/image/C4D12AQFFQpcswzEAdg/article-inline_image-shrink_1000_1488/0/1555499709349?e=1721865600&v=beta&t=upkHAvA3gbJDTvX-NYc_rkaz8ywua8lrsTG23VEZpLY align="left")

In the next scenario, there is a status item that I set to a value (OK) when the process can be called; can I check this item value before calling the application process? The malicious user may also know the JavaScript below.

![No alt text provided for this image](https://media.licdn.com/dms/image/C4D12AQFbWEoShm6ttQ/article-inline_image-shrink_1000_1488/0/1555499739371?e=1721865600&v=beta&t=Cf82GrOupRgCqGFGesBXO5Trz77EQqJCNLEqmrzTpVU align="left")

We need also insure that each page has access protection, otherwise the hacker can set inject values in the URL.

![No alt text provided for this image](https://media.licdn.com/dms/image/C4D12AQH2CWu5Ll9Kgg/article-inline_image-shrink_400_744/0/1555499759541?e=1721865600&v=beta&t=kwCOGBudmS6DMW8IG1bXmpBT21sVckK_S7_u9kZKwA0 align="left")

Available options include:

* Unrestricted
    

The page may be requested using a URL, with or without session state arguments, and without having to have a checksum. The URL below includes the RIR request and set the value 1 for the P4\_ITEM.

[https://apex.oracle.com/pls/apex/f?p=107300:4:6447557498631::NO:RIR:P4\_ITEM:1](https://apex.oracle.com/pls/apex/f?p=107300:4:6447557498631::NO:RIR:P4_ITEM:1)

* Arguments Must Have Checksum
    

If Request, Clear Cache, or Name/Value Pair arguments appear in the URL, a checksum must also be provided. The URL below includes the RIR request, set the value 1 for the P4\_ITEM and include a checksum.

[https://apex.oracle.com/pls/apex/f?p=107300:4:6447557498631::NO:RIR::&cs=3hd-mtPQg-gw57elJnXo00nw5HlLLYFLePj5bMh0g8-Ybk–yuRYH8f0RHF6Pcl0HJc1LpyJ6fCOkjAvBY3oeog](https://apex.oracle.com/pls/apex/f?p=107300:4:6447557498631::NO:RIR::&cs=3hd-mtPQg-gw57elJnXo00nw5HlLLYFLePj5bMh0g8-Ybk–yuRYH8f0RHF6Pcl0HJc1LpyJ6fCOkjAvBY3oeog)

If we manually try to change the value, 1 to another one, the user will get the following error.

*Session state protection violation: This may be caused by manual alteration of a URL containing a checksum or by using a link with an incorrect or missing checksum. If you are unsure what caused this error, please contact the application administrator for assistance.*

* No Arguments Supported
    

A URL may be used to request the page, but the URL cannot contain Request, Clear Cache, or Name/Value Pair arguments.

* No URL Access
    

The page may not be accessed using a URL.

However, the page may be the target of a Branch to Page branch type, as this does not perform a URL redirect.

Tips:

1. Avoid by applying conditions to the application process that check page items.
    
2. Create page validations to double check using the same rule that made the button disabled.
    
3. Use APEX authorization schemes to validate page access. Even if a page is not available on the menu to a specific user, the user can set the page number in the page URL ([https://apex.oracle.com/pls/apex/f?p=107300:**4**:6447557498631::NO](https://apex.oracle.com/pls/apex/f?p=107300:4:6447557498631::NO):::) and go to the page if there is no authorization is selected. To create authorization schemes, go to Shared Components \\ Authorization Schemes and then any that you create will be available in the page properties.
    

![No alt text provided for this image](https://media.licdn.com/dms/image/C4D12AQHKDNWExvkk4g/article-inline_image-shrink_400_744/0/1555500033144?e=1721865600&v=beta&t=gV93KnbbN8qiWa8Quvx09jzIZtcZg_Ul6n3Zcfcyv_w align="left")

Summary:

APEX is very safe and used by numerous military and classified agencies around the world, but like most web technologies, the developers needs to know and use the security resources in order to avoid breaches that could make the app vulnerable.