15.2 Understanding Developer Security Best Practices

This section describes security best practices for Oracle Application Express developers.

Topics:

15.2.1 Understanding Items of Type Password

Password items do not emit the text entered to the web browser screen. When creating password items, Oracle recommends using password attributes that do not save session state. This prevents the password from being saved in the database in the session state tables.

Configurable password item type attributes include:

  • Value Required - If set to Yes and the page item is visible, Oracle Application Express automatically performs a NOT NULL validation when the page is submitted. If set to No, no validation a NULL value is accepted.

  • Submit when Enter pressed - If set to Yes, when the user presses the ENTER key in the field the page is submitted.

  • Does not save state - If set to Yes, the password is not saved into session state. For security reasons you should always set this attribute to Yes. If you set it to No, consider to set the attribute Store value encrypted in session state to Yes.

  • Authorization Scheme - Optionally select an authorization scheme which must evaluate to TRUE in order for this component to be rendered or otherwise processed.

  • Session State Protection - You can select the level of session state protection by setting this attribute to Unrestricted or Restricted.

    • Unrestricted means the item may be set by passing the item in a URL or in a form. No checksum is required in the URL.

    • Restricted means the item may not be set from a browser. Use this when you want to restrict the way that the item value can be set to internal processes, computations, and so on. This attribute is applicable only to items that cannot be used as data entry items and is always observed, even if Session State Protection is disabled.

  • Store value encrypted in session state - Session state that is sensitive can be encrypted when stored in Application Express session state management tables. To maintain session state encrypted for this item set the value to Yes. To learn more, see "About Session State and Security".

See Also:

"About Item Types" and "Editing Page-Level Items"

15.2.2 Identifying At Risk Password Items

At risk password items are those that either:

  • Do not use a password item type that does not save session state

  • Store the value in session state un-encrypted

Use the Security Profiles and Password Items reports to help identify at risk password items.

Topics:

15.2.2.1 Viewing the Security Profiles Report

To view the Security Profiles Report:

  1. Navigate to the Workspace home page.

  2. Click the Application Builder icon.

    The Application Builder home page appears.

  3. On the Tasks list, click Cross Application Reports.

  4. Under Security, click Security Profiles report.

    This report list the following information about all applications in the current workspace:

    • Application

    • Name

    • Parsing Schema

    • Application Level Authorization Scheme

    • Authentication

    • Authorization Schemes

    • Authorization Schemes

    • Pages

    • Encrypted Items

    • At Risk Password Items

15.2.2.2 Viewing the Password Items Report

To identify at risk password items:

  1. Navigate to the Workspace home page.

  2. Click the Application Builder icon.

    The Application Builder home page appears.

  3. On the Tasks list, click Cross Application Reports.

  4. Under Security, click Password Items.

    The Password Items report shows all of the password items within the application and indicates if they use encryption and whether they save state. Password items that do neither are highlighted as At Risk.

Tip:

For pages that contain password items, set the page attribute Form Auto Complete to Off. Setting that attribute to Off prevents the web browser from attempting to auto complete items on the page.

15.2.3 Understanding Cross-Site Scripting Protection

Cross site-scripting (also referred to as XSS) is a security breach that takes advantage of dynamically generated web pages. In a XSS attack, a web application is sent a script that activates when it is read by a user's browser. Once activated, these scripts can steal data, even session credentials, and return the information to the attacker.

If malicious code were introduced into an Oracle Application Express application, it could be rendered into HTML regions and other places within the application during normal page rendering. To prevent the introduction of malicious code into session state, the Application Express engine escapes characters in certain cases.

Topics:

15.2.3.1 Protecting HTML Regions and Other Static Areas

In HTML regions and other static display areas, you can reference session state using the &ITEM. notation. Examples of static display areas include HTML regions, page headers and footers, region headers and footers, region titles, button labels, help text, form item labels and post-element text, templates, radiogroup (before and after field text), event success messages, event error messages, navigation bar attributes, application static substitution string values, chart labels and legends, breadcrumbs and list framing text, and calendar text, labels, or legends.

15.2.3.1.1 About Safe Item Display Types

When session state is referenced in this way, the value emitted to the page will not have special characters (<, >, &, ") escaped if the referenced item is Display Only with the attribute Save Session State set to No.

If the referenced item has a display type other than Display Only with the attribute Save Session State set to No, the value emitted to the page will have special characters escaped. Although application-level items are also considered to have a safe display type, they do not actually have display properties like form items do.

See Also:

"Understanding Page-Level Items"

15.2.3.1.2 About the Rules Used to Determine Whether to Escape Values

The Application Express engine uses predefined smart escaping rules to determine if and when to escape values fetched from session state.

The reason for these rules is that items that use the display types listed previously are often for text containing HTML that is intended to be emitted to the browser without being filtered (that is, escaped). The only way this can be made safe is by the enforcement of the rule that these types of items are always escaped on input to the application. For example, if a user passes some text into a safe item using an Oracle Application Express f?p URL syntax, the Application Express engine escapes special characters when saving the value into session state. This has two intended results:

  1. If the value contained no special characters, the value passed in is saved into session state exactly as it was provided.

  2. If the value contained special characters, those characters are escaped when the value is saved into session state.

In either situation, the item can now safely be referenced using an &ITEM. notation in any HTML region or other static area mentioned previously.

15.2.3.1.3 Using Safe Item Types to Hold and Emit HTML Markup

You can use the safe item types listed previously to hold and emit HTML markup to the browser. For example, suppose you have a requirement to render some text in bold face by referencing a safe page item named P1_XXX (using &P1_XXX.) The item P1_XXX is presumed to contain the following HTML:

<b>ABABABAB</b>

You can achieve this by using application controls (computations, processes, item source expressions, item default values, and so on) to store values into these safe items. When values are introduced in this way, you ensure the safety of the content. When you use these methods, the Application Express engine does not escape any special characters when saving the values into session state.

Finally, the safety of safe items is ensured by a rule that prevents those items from being posted on a page and submitted to the Application Express engine as part of a page submission.

15.2.3.2 Protecting Dynamic Output

Items fetched from session state and rendered using htp.p or other methods should be explicitly escaped by the code where it is appropriate to do so. For example, suppose a PL/SQL dynamic content region on a page uses the following:

 htp.p(v(&rsquor;SOME_ITEM'));

If the value of the item fetched from session state could contain unintended tags or scripts, you might want to use the following in the region:

htp.p(apex_escape.html(:SOME_ITEM));

However, if you are confident that the fetched value is safe for rendering, you do not need to escape the value. As a developer, you must determine when it is appropriate to not escape output.

As a best practice, follow this rule:

The reason for this is that as a developer, there is no way you can prevent a hacker from posting a malicious value into a non-safe item. Even if your application does not present these items visibly to ordinary users, be aware that a hacker can mount a XSS attack using your application if you do not follow this rule.

15.2.3.3 Protecting Report Regions

The Application Express engine escapes data rendered in the body of a report. References to session state in report headings and messages are fetched from session state using the smart escaping rules so that the values of safe item types are not escaped and the values of other item types are escaped.

15.2.3.4 Protecting Form Items

When form items, including hidden items, obtain their values during the generation of the form page to be sent to the browser, the resulting text is escaped before rendering. Some of the safe item types are exceptions to this rule to support the intended behavior of each display type.

Some item types have the attribute Escape special characters in the Security region. Use this attribute to specify if the value should be escaped or not. The default is set to Yes. To display HTML code, set this attribute to No.

15.2.3.5 Restricting Characters Entered on an Item

You can limit cross site-scripting and other injection attacks by restricting the characters users can enter on an item. To accomplish this, use the Restricted Characters attribute in the Security region of the Edit Page Item page.

Use the Restricted Characters to restrict the characters that can be saved in session state. Available options include:

  • All Characters Allowed

    No restriction applies.

  • Whitelist for a-Z, 0-9 and space

    Only allow characters a-z, A-Z, 0-9, and space.

  • Blacklist HTML command characters (<>").

    Do not allow reserved HTML characters

  • Blacklist &<>"/;,*|=% and --:

    Do not allow &, <, >, ", /, ;, ",", *, |, =, % and "--" (PL/SQL comment).

  • Blacklist &<>"/;,*|=% or -- and new line

    Do not allow &, <, >, ", /, ;, ",", *, |, =, %, "--", and new line characters

If you select a restriction, Oracle Application Express displays an error message if a user tries to save data which does not conform to the selected character restriction.

See Also:

"Configuring Page Item Security"

15.2.4 About Session State and Security

Oracle Application Express persists session state in database tables. Session state is preserved in database tables because it is more secure to store the session state on the server side than on the client. Because Oracle Application Express applications use the stateless HTTP protocol, an application's session state across multiple page views is preserved in database tables. Not maintaining a synchronous database connection for each Oracle Application Express application user significantly lessens memory and database resource requirements.

Developers can query the session state stored by Oracle Application Express applications using the Application Builder and built-in monitoring pages. Developers and administrators can access session state for any application in the workspace to which they are authenticated.

A few best practices for developers include:

  • As a standard part of implementing program control flow, clear the session state of unneeded values using clear-cache page processes or clear-cache directives in URLs used to navigate to pages.

  • Use password page item types that do not save state. This prevents the entered passwords from being saved in session state tables in the database.

  • When sensitive data must persist in a session, it should be saved in Oracle Application Express session state tables in encrypted form. To use this feature, set the page item's Store value encrypted in session state attribute to Yes. Encrypted stored values are automatically decrypted when read.

Note:

The objective of encrypted session state is to persist session state such that the unencrypted values cannot be read by other Oracle Application Express developers or database administrators who might have access to the Oracle Application Express session state tables, debug output, or database data files. Oracle recommends that database backups be performed using facilities that encrypt data in the backup files.

Tip:

You can encrypt item values up to 4000 bytes in length. Attempts to encrypt values longer than 4000 bytes produces an error message.

15.2.5 Understanding Session State Protection

Session State Protection is a built-in functionality that prevents hackers from tampering with the URLs within your application. URL tampering can adversely affect program logic, session state contents, and information privacy.

Enabling Session State Protection is a two-step process. First, you enable the feature. Second, you set page and item security attributes.

Topics:

15.2.5.1 How Session State Protection Works

When enabled, Session State Protection uses the Page Access Protection attributes and the Session State Protection item attributes with checksums positioned in f?p= URLs to prevent URL tampering and unauthorized access to and alteration of session state. When Session State Protection is disabled, the page and item attributes related to session state protection are ignored and checksums are not included checksums in generated f?p= URLs.

15.2.5.2 Enabling Session State Protection

You can enable session state protection from either the Edit Security Attributes page or the Session State Protection page.

Enabling Session State Protection is a two-step process. First, you enable the feature. Second, you set page and item security attributes. You can perform these steps using a wizard, or you can set security attributes for pages and items manually on the Session State Protection page.

Topics:

15.2.5.2.1 Enabling Session State Protection from Edit Security Attributes

To enable Session State Protection from the Edit Security Attributes page:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

  3. Click the Shared Components icon.

  4. Under Security, click Security Attributes.

  5. Scroll down to Session State Protection and select Enabled from the Session State Protection list.

  6. To configure session Session State Protection, click Manage Session State Protection.

    The Session State Projection page appears.

  7. To enable, disable, or configure Session State Protection using a wizard, click Set Protection.

  8. Otherwise, navigate to the appropriate page or item attributes page and configure the Security attributes.

Tip:

To disable Session State Protection, perform the same steps again, but select Disabled instead of Enabled. Disabling Session State Protection does not change existing security attribute settings, but those attributes are ignored at runtime.

15.2.5.2.2 About the Expire Bookmarks Button

Enabling Session State Protection affects whether bookmarked links to the current application work. Consider the following rules:

  1. Bookmarked links created after Session State Protection is enabled work if the bookmarked link contains a checksum.

  2. Bookmarked links created before Session State Protection is enabled do not work if the bookmarked link contains a checksum.

  3. Bookmarks that do not contain checksums or contain unnecessary checksums are not affected by Session State Protection.

During page rendering, the Application Express engine uses a hidden application attribute (a checksum salt) during computation and to verify checksums included in f?p URLs. When you enable Session State Protection, the Application Express engine includes checksums. You can reset the checksum salt attribute by clicking Expire Bookmarks on the Edit Security Attributes page. Note that if you click Expire Bookmarks, bookmarked URLs used to access your application that contain previously generated checksums will fail.

15.2.5.2.3 Enabling Session State Protection from Session State Protection

To enable Session State Protection:

  1. Navigate to the Shared Components page:

    1. On the Workspace home page, click the Application Builder icon.

    2. Select an application.

    3. Click Shared Components.

    4. Under Security, select Session State Protection.

    The Session State Protection page appears. Note the current Session State Protection status (Enabled or Disabled) displays at the top of the page.

  2. Click the Set Protection button.

    The Session State Protection wizard appears.

  3. Under Select Action, select Enable and click Next.

    Next, determine whether to set security attributes for pages and items.

  4. Select Enable and click Next.

  5. Click Enable Session State Protection.

Tip:

To disable Session State Protection, perform the same steps, but select Disable instead of Enable. Disabling Session State Protection does not change existing security attribute settings, but those attributes are ignored at runtime.

15.2.5.3 Configuring Session State Protection

Once you have enabled Session State Protection, the next step is to configure security attributes. You can configure security attributes in two ways:

  • Use a wizard and select a value for specific attribute categories. Those selections are then applied to all pages and items within the application.

  • Configure values for individual pages, items, or application items.

Topics:

Tip:

Before you can configure security attributes, you must first enable Session State Protection. See "Enabling Session State Protection".

15.2.5.3.1 Reviewing Existing Session State Protection Settings

You can review a summary of Session State Protection settings for pages, items, and application items on the first page of the Session State Protection wizard.

To view summaries of existing Session State Protection settings:

  1. Navigate to the Session State Protection page:

    1. On the Workspace home page, click the Application Builder icon.

    2. Select an application.

    3. Click Shared Components.

    4. Under Security, select Session State Protection.

      The Session State Protection page appears.

  2. Click Set Protection.

  3. Expand the following reports at the bottom of the page:

15.2.5.3.2 Configuring Session State Protection Using a Wizard

When you configure Session State Protection using a wizard, you set a value for specific attribute categories. Those selections are then applied to all pages and items within the application.

To configure Session State Protection using a wizard:

  1. Navigate to the Session State Protection page:

    1. On the Workspace home page, click the Application Builder icon.

    2. Select an application.

    3. Click Shared Components.

    4. Under Security, select Session State Protection.

      The Session State Protection page appears.

  2. Click Set Protection.

    The Session State Protection wizard appears.

  3. Under Select Action, select Configure and click Next.

  4. For Page Access Protection, select one of the following:

    • Unrestricted - The page may be requested using a URL with or without session state arguments (Request, Clear Cache, Name/Values).

    • Arguments Must Have Checksum - If Request, Clear Cache, or Name/Value arguments appear in the URL, a checksum must also be provided. The checksum type must be compatible with the most stringent Session State Protection attribute of all the items passed as arguments.

    • No Arguments Allowed - A URL may be used to request the page but no Request, Clear Cache, or Name/Value arguments are allowed.

    • 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, which does not do a URL redirect.

  5. For Application Item Protection, select one of the following:

    • Unrestricted - The item's session state may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.

      Note: If you must set this item's value in session state using Ajax, then an Unrestricted protection level must be used for the item (for example in Dynamic Actions, Set Value, Page Items to Submit or Cascading LOVs, Page Items to Submit).

    • Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. You can also use a user-level checksum or a session-level checksum (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.

    • Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. You can also use a session-level checksum (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.

    • Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is also provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.

    • Restricted - May not be set from browser - The item may not be altered using the URL or POSTDATA. Use this option when you want to restrict the way that the item value can be set to internal processes, computations, and so on. This attribute is applicable only to items that cannot be used as data entry items and is always observed even if Session State Protection is disabled.

      Use this attribute for application items or for page items with any of these Display As types:

      • Display as Text (escape special characters, does not save state)

      • Display as Text (does not save state)

      • Display as Text (based on LOV, does not save state)

      • Display as Text (based on PLSQL, does not save state)

      • Text Field (Disabled, does not save state)

      • Stop and Start HTML Table (Displays label only)

  6. For Page Data Entry Item Protection, select one of the following:

    • Unrestricted - The item's session state may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.

      Note: If you must set this item's value in session state using Ajax, then an Unrestricted protection level must be used for the item (for example in Dynamic Actions, Set Value, Page Items to Submit or Cascading LOVs, Page Items to Submit).

    • Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. You can also use a user-level checksum or a session-level checksum (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.

    • Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. You can also use a session-level checksum (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.

    • Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.

  7. For Page Display-Only Item Protection, select one of the following:

    • Unrestricted - The item may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.

      Note: If you must set this item's value in session state using Ajax, then an Unrestricted protection level must be used for the item (for example in Dynamic Actions, Set Value, Page Items to Submit or Cascading LOVs, Page Items to Submit).

    • Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. You can also use a user-level checksum or a session-level checksum (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.

    • Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.

    • Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. You can also use a session-level checksum. Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.

    • Restricted: May not be set from browser - The item may not be altered using the URL or POSTDATA. Use this when you want to restrict the way that the item value can be set to internal processes, computations, and so on. This attribute is always observed, even if Session State Protection is disabled.

      This attribute may be used with any of these Display As types:

      • Display as Text (escape special characters, does not save state)

      • Display as Text (does not save state)

      • Display as Text (based on LOV, does not save state)

      • Display as Text (based on PLSQL, does not save state)

      • Text Field (Disabled, does not save state)

      • Stop and Start HTML Table (Displays label only)

  8. Click Next.

  9. Click Finish.

15.2.5.3.3 Configuring Session State Protection for Pages

To configure Session State Protection for Pages:

  1. Navigate to the Session State Protection page:

    1. On the Workspace home page, click the Application Builder icon.

    2. Select an application.

    3. Click Shared Components.

    4. Under Security, select Session State Protection.

      The Session State Protection page appears.

  2. Click the Page icon.

  3. You can customize the appearance the page using the Search bar at the top of the page. Available controls include:

    • Search icon - Resembles a magnifying glass. Click this icon to narrow your search to only specific columns. To search all columns, select All Columns.

    • Text area - Enter case insensitive search criteria (wildcard characters are implied) and then click Go.

    • Go button - Executes a search or applies a filter.

    • View Chart. Use this control to view information as a chart.

    • Actions menu - Displays the Actions menu. Use this menu to customize this interactive report. See "About the Actions Menu".

  4. Select a page number.

    The Set Page and Item Protection page appears. The following information displays at the top of the page:

    • Application ID and name

    • Session State Protection status (Enabled or Disabled)

    • Page Number

    • Page name

  5. For Page Access Protection, select one of the following:

    • Unrestricted - The page may be requested using a URL with or without session state arguments (Request, Clear Cache, Name/Values).

    • Arguments Must Have Checksum - If Request, Clear Cache, or Name/Value arguments appear in the URL, a checksum must also be provided. The checksum type must be compatible with the most stringent Session State Protection attribute of all the items passed as arguments.

    • No Arguments Allowed - A URL may be used to request the page but no Request, Clear Cache, or Name/Value arguments are allowed.

    • 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, which does not do a URL redirect.

  6. For Item Types, select Data Entry Items or Display-only Items.

    Data Entry items are items that can be altered using forms and include hidden items. Display-Only items are rendered only and are not submitted with the form.

  7. If you select Data Entry Items, select a session state protection level for each item:

    • Unrestricted - The item's session state may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.

      Note: If you must set this item's value in session state using Ajax, then an Unrestricted protection level must be used for the item (for example in Dynamic Actions, Set Value, Page Items to Submit or Cascading LOVs, Page Items to Submit).

    • Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. You can also use a user-level checksum or a session-level checksum (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.

    • Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. You can also use a session-level checksum (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.

    • Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.

  8. If you select Display-only Item, select a session state protection level for each item:

    • Unrestricted - The item may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.

      Note: If you must set this item's value in session state using Ajax, then an Unrestricted protection level must be used for the item (for example in Dynamic Actions, Set Value, Page Items to Submit or Cascading LOVs, Page Items to Submit).

    • Restricted: May not be set from browser - The item may not be altered using the URL or POSTDATA. Use this when you want to restrict the way that the item value can be set to internal processes, computations, and so on. This attribute is always observed, even if Session State Protection is disabled. This attribute may be used with any of these Display As types:

      • Display as Text (escape special characters, does not save state)

      • Display as Text (does not save state)

      • Display as Text (based on LOV, does not save state)

      • Display as Text (based on PLSQL, does not save state)

      • Text Field (Disabled, does not save state)

      • Stop and Start HTML Table (Displays label only)

    • Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. You can also use a user-level checksum or a session-level checksum (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.

    • Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. You can also use a session-level checksum (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.

    • Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.

  9. Click Apply Changes.

15.2.5.3.4 Configuring Session State Protection for Page Items

To configure Session State Protection for items:

  1. Navigate to the Session State Protection page:

    1. On the Workspace home page, click the Application Builder icon.

    2. Select an application.

    3. Click Shared Components.

    4. Under Security, select Session State Protection.

      The Session State Protection page appears.

  2. Click the Page Item icon.

  3. You can customize the appearance the page using the Search bar at the top of the page. Available controls include:

    • Search icon - Resembles a magnifying glass. Click this icon to narrow your search to only specific columns. To search all columns, select All Columns.

    • Text area - Enter case insensitive search criteria (wildcard characters are implied) and then click Go.

    • Go button - Executes a search or applies a filter.

    • Actions menu - Displays the Actions menu. Use this menu to customize the report view. See "About the Actions Menu".

  4. Select a page number.

    The Edit Session State Protection for Page and Items page appears. The following information displays at the top of the page:

    • Application ID and name

    • Session State Protection status (Enabled or Disabled)

    • page Number

    • Page name

  5. For Page Access Protection, select a session state protection level for each item:

    • Unrestricted - The page may be requested using a URL with or without session state arguments (Request, Clear Cache, Name/Values).

    • Arguments Must Have Checksum - If Request, Clear Cache, or Name/Value arguments appear in the URL, a checksum must also be provided. The checksum type must be compatible with the most stringent Session State Protection attribute of all the items passed as arguments.

    • No Arguments Allowed - A URL may be used to request the page but no Request, Clear Cache, or Name/Value arguments are allowed.

    • 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, which does not do a URL redirect.

  6. For Item Types, select Data Entry Items or Display-only Items.

    Data Entry items are items that can be altered using forms and include hidden items. Display-Only items are rendered only and are not submitted with the form.

  7. If you select Data Entry Items, select a session state protection level for each item:

    • Unrestricted - The item's session state may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.

      Note: If you must set this item's value in session state using Ajax, then an Unrestricted protection level must be used for the item (for example in Dynamic Actions, Set Value, Page Items to Submit or Cascading LOVs, Page Items to Submit).

    • Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. You can also use a user-level checksum or a session-level checksum (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.

    • Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. You can also use a session-level checksum (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.

    • Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.

  8. If you select Display-only Item, select a session state protection level for each item:

    • Unrestricted - The item may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.

      Note: If you must set this item's value in session state using Ajax, then an Unrestricted protection level must be used for the item (for example in Dynamic Actions, Set Value, Page Items to Submit or Cascading LOVs, Page Items to Submit).

    • Restricted: May not be set from browser - The item may not be altered using the URL or POSTDATA. Use this when you want to restrict the way that the item value can be set to internal processes, computations, and so on. This attribute is always observed, even if Session State Protection is disabled. This attribute may be used with any of these Display As types:

      • Display as Text (escape special characters, does not save state)

      • Display as Text (does not save state)

      • Display as Text (based on LOV, does not save state)

      • Display as Text (based on PLSQL, does not save state)

      • Text Field (Disabled, does not save state)

      • Stop and Start HTML Table (Displays label only)

    • Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. You can also use a user-level checksum or a session-level checksum (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.

    • Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. You can also use a session-level checksum (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.

    • Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.

  9. Click Apply Changes.

15.2.5.3.5 Configuring Session State Protection for Application Items

To configure Session State Protection for application items:

  1. Navigate to the Session State Protection page:

    1. On the Workspace home page, click the Application Builder icon.

    2. Select an application.

    3. Click Shared Components.

    4. Under Security, select Session State Protection.

      The Session State Protection page appears.

  2. Click the Application Item icon.

  3. You can customize the appearance the page using the Search bar at the top of the page. Available controls include:

    • Search icon - Resembles a magnifying glass. Click this icon to narrow your search to only specific columns. To search all columns, select All Columns.

    • Text area - Enter case insensitive search criteria (wildcard characters are implied) and then click Go.

    • Go button - Executes a search or applies a filter.

    • Actions menu - Displays the Actions menu. Use this menu to customize the report view. See "About the Actions Menu".

  4. Select an application item.

  5. Under Security, select one of the following from the Session State Protection list:

    • Unrestricted - The item's session state may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.

      Note: If you must set this item's value in session state using Ajax, then an Unrestricted protection level must be used for the item (for example in Dynamic Actions, Set Value, Page Items to Submit or Cascading LOVs, Page Items to Submit).

    • Restricted - May not be set from browser - The item may not be altered using the URL or POSTDATA. Use this option when you want to restrict the way that the item value can be set to internal processes, computations, and so on. This attribute is only applicable only to items that cannot be used as data entry items and is always observed even if Session State Protection is disabled. This attribute may be used for application items or for page items with any of these Display As types:

      • Display as Text (escape special characters, does not save state)

      • Display as Text (does not save state)

      • Display as Text (based on LOV, does not save state)

      • Display as Text (based on PLSQL, does not save state)

      • Text Field (Disabled, does not save state)

      • Stop and Start HTML Table (Displays label only)

    • Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. You can also use a user-level checksum or a session-level checksum (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.

    • Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. You can also use a session-level checksum (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.

    • Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.

  6. Click Apply Changes.