Security Risk List

The security risk list or “white list” enables URL-like parameters from the portal to be integrated into AS-ABAP. Method CL_HTTP_UTILITY=>IF_HTTP_UTILITY~CHECK_HTTP_WHITELIST is available for this purpose.

In white list patterns are configured with which URLs from external sources are compared.  This process verifies that these URLs can be accepted. The white list is stored in table HTTP_WHITELIST, which can be changed in transaction SE16.


Each table record has the following structure:

·        entry_type

URL type to be compared with this entry.

Example: CSS off-box reference

·        host

Host name that is compared with the inbound host. This field is empty if the host name is not checked for a specific entry. The placeholder (*) can be used.

·        protocol

Protocol to be checked. Usually this is HTTP or HTTPS. This field can be empty if not check is to be made.

·        port

Port number to be checked. Must be numeric. Leave empty if it is not to be checked.

·        url

URL for checking the inbound URL. The placeholder (*) can be used.

If there are no entries in table HTTP_WHITELIST no checks are made.

As soon as the URL with its separate parts is available, the table is compared with the white list. This table also contains the separate parts of the URL, which are compared one after the other.

With the entry type various types of white lists can be configured. Usually the server from which CSS themes can be loaded is defined in the white list. These CSS themes are loaded by generating a URL pointer in the HTML that is supplied with the themes and that leads back to the portal server.

If no parameters are specified, then none are checked. It is assumed that they are correct.

If a masking character (*) is specified, it is compared to the received string.

URL Examples


Standard Port/Standard Root



Standard port 80


Standard port 443


Standard root URL


Standard root URL


No host data specified

·         Example 1:

white list protocol =  (empty string)

This implicitly means that the protocol is not checked. All URLs in the form http[s]://... oder /... are allowed through as no check is made whether a protocol has been set.

·         Example 2:

white list protocol = *

The protocol is checked whether any value has been defined for it. All URLs in the form http[s]://... are allowed through. URLs in the form /... are however not accepted as according to this rule no protocol is available.

·         Example 3:

white list protocol = https

Only URLs in the form https://... are allowed through.

The most simple case is to use a white list with empty fields and not to make any checks. The purpose of the white list table is however to offer a level of security that is required by customers.

For instance you could have a portal server that provides URLs that point to the portal themes (CSS files). For the first security level you could use a white list filter in the following form:

    protocol=*, host=*.myDomain.myExt, port=*, url=

With this all references to another computer in the same domain would be accepted.

A scenario is also possible that restricts the load to just this one portal server. This would look like:

    protocol=*, host=myPortal.myDomain.myExt, port=*, url=

In this case there are various security loopholes. For example, another Web server can be installed on the same portal server. The portal server is secure, but not necessarily the Web server. The URLs would still pass through the white list. To close all security loopholes completely, you should always specify the protocol as well as the port:

    protocol=http,  host=myPortal.myDomain.myExt, port=1080, url=/*

    protocol=https, host=myPortal.myDomain.myExt, port=1443, url=/*

By default the white list table is empty and no checks are made.


This method checks whether a received URL matches with a white list stored in a local database.  The URL, which serves as an input parameter, is either an absolute URL or a server-specific absolute URL.