This section describes security best practices for Oracle Application Express developers.
See Also:
"Understanding Administrator Security Best Practices" and "About Application Express User Roles"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".
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.
This section explains how to use the Security Profiles and Password Items reports to help identify at risk password items.
To view the Security Profiles Report:
Navigate to the Workspace home page.
Click the Application Builder icon.
The Application Builder home page appears.
Click the Workspace Utilities icon.
Locate Cross Application Reports on the right side of the window.
Under Cross Application Reports, 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
To identify at risk password items:
Navigate to the Workspace home page.
Click the Application Builder icon.
The Application Builder home page appears.
Click the Workspace Utilities icon.
Locate Cross Application Reports on the right side of the window.
Under Cross Application Reports, 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.This section explains best practices for protecting your application from a cross site-scripting security breach.
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.
This section explains how to protect HTML regions and other static display areas.
In HTML regions and other static display areas, you can reference session state using the substitution strings. Special substitution strings available within a template are denoted by the number symbol (#), for example, #ABC#. To reference page or application items use 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.
Developers can also append an exclamation mark (!) followed by a predefined filter name to a page or application item name or to a report column reference to escape special characters in the substitution value.
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 and Escape Special 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"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:
If the value contained no special characters, the value passed in is saved into session state exactly as it was provided.
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.
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.
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('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:
Never emit an item fetched from session state without escaping it unless the item is a safe type described in "About Safe Item Display Types".
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.
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.
Oracle Application Express automatically escapes HTML special characters of a report column when the column's Escape special characters attribute is set to Yes. If you need to render HTML fragments instead of plain column values (for example, for highlighting), instead of concatenating the HTML fragment in the query itself (which prevents you from using Escape special characters), you should use the report column's HTML Expression attribute. In the HTML Expression attribute, you can enter static HTML and embed escaped column values with the #COLUMN# notation. The extended column notation gives you control regarding how Oracle Application Express should escape a column value:
#COLUMN!HTML# - Escapes reserved HTML characters.
#COLUMN!ATTR# - Escapes reserved characters in a HTML attribute context.
#COLUMN!JS# - Escapes reserved characters in a JavaScript context.
#COLUMN!RAW# - Preserves the original item value and does not escape characters.
#COLUMN!STRIPHTML# - Removes HTML tags from the output and escapes reserved HTML characters.
For example, suppose you have a report based on this query:
SELECT
empno,
ename,
NULL DELETE_LINK
FROM emp
In this example, all columns are escaped. You could define a HTML Expression on DELETE_LINK as follows:
<a href="javascript:if (confirm('Do you really want to delete #ENAME!JS#?')) doSubmit('DELETE-#EMPNO#');">Delete</a>
This example renders a link that asks if you would like to delete an employee and submits a request to delete the row if the user is confirmed. If you had not used #ENAME!JS# but #ENAME#, a name like O'Neill would cause a syntax error and an attacker could exploit the improper escaping for cross-site scripting.
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 Security attribute Escape special characters. Use the Escape special characters 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.
Developers can also append an exclamation mark (!) followed by a predefined filter name to a page or application item name or to a report column reference, to escape special characters in the substitution value.
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. Restricted Characters 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.
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.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.
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.
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.
Enabling Session State Protection from Edit Security Attributes
Enabling Session State Protection from Session State Protection
To enable Session State Protection from the Edit Security Attributes page:
On the Workspace home page, click the Application Builder icon.
Select an application.
Click the Shared Components icon.
Under Security, click Security Attributes.
Scroll down to Session State Protection and select Enabled from the Session State Protection list.
To configure session Session State Protection, click Manage Session State Protection.
The Session State Projection page appears.
To enable, disable, or configure Session State Protection using a wizard, click Set Protection.
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.Enabling Session State Protection affects whether bookmarked links to the current application work. Consider the following rules:
Bookmarked links created after Session State Protection is enabled work if the bookmarked link contains a checksum.
Bookmarked links created before Session State Protection is enabled do not work if the bookmarked link contains a checksum.
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.
Tip:
Be aware that if you click Expire Bookmarks, bookmarked URLs used to access your application that contain previously generated checksums will fail.On the Confirm Invalidate Bookmarks page, you can also configure the Bookmark Checksum Function which is the hash algorithm used for computing bookmark checksums.
To enable Session State Protection:
Navigate to the Shared Components page:
On the Workspace home page, click the Application Builder icon.
Select an application.
Click Shared Components.
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.
Click the Set Protection button.
The Session State Protection wizard appears.
Under Select Action, select Enable and click Next.
Next, determine whether to set security attributes for pages and items.
Select Enable and click Next.
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.Tip:
Before you can configure security attributes, you must first enable Session State Protection. See "Enabling 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.
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:
Navigate to the Session State Protection page:
On the Workspace home page, click the Application Builder icon.
Select an application.
Click Shared Components.
Under Security, select Session State Protection.
The Session State Protection page appears.
Click Set Protection.
Expand the following reports at the bottom of the page:
Page Level Session State Protection Summary
Page Item Session State Protection Summary
Application Item Session State Protection
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:
Navigate to the Session State Protection page:
On the Workspace home page, click the Application Builder icon.
Select an application.
Click Shared Components.
Under Security, select Session State Protection.
The Session State Protection page appears.
Click Set Protection.
The Session State Protection wizard appears.
Under Select Action, select Configure and click Next.
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.
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)
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.
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)
Click Next.
Click Finish.
To configure Session State Protection for Pages:
Navigate to the Session State Protection page:
On the Workspace home page, click the Application Builder icon.
Select an application.
Click Shared Components.
Under Security, select Session State Protection.
The Session State Protection page appears.
Click the Page icon.
You can customize the appearance the page using the Search bar at the top of the page. To learn more, see "About the Search Bar."
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
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.
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.
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.
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.
Click Apply Changes.
To configure Session State Protection for items:
Navigate to the Session State Protection page:
On the Workspace home page, click the Application Builder icon.
Select an application.
Click Shared Components.
Under Security, select Session State Protection.
The Session State Protection page appears.
Click the Page Item icon.
You can customize the appearance the page using the Search bar at the top of the page. To learn more, see "About the Search Bar."
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
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.
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.
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.
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.
Click Apply Changes.
To configure Session State Protection for application items:
Navigate to the Session State Protection page:
On the Workspace home page, click the Application Builder icon.
Select an application.
Click Shared Components.
Under Security, select Session State Protection.
The Session State Protection page appears.
Click the Application Item icon.
You can customize the appearance the page using the Search bar at the top of the page. To learn more, see "About the Search Bar."
Select an application item.
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.
Click Apply Changes.
Oracle Application Express enables you to easily build an application that can be used to upload files and to access uploaded files. These files are uploaded into a common file storage table. Although the database view APEX_APPLICATION_FILES shows those files associated with your database account (or workspace), programmatic access to the common file storage table does not always require authentication, enabling other users to see your uploaded files. For this reason, Oracle recommends that developers either use the methods described in "Understanding BLOB Support in Forms and Reports" or use the methods described in Oracle Application Express How To Documents for file upload on OTN at:
http://www.oracle.com/technetwork/developer-tools/apex/overview/index.html
Either of these methods results in the uploaded files being stored in schema tables and not the public table.
See Also:
"About the Differences Between Page Items and Application Items" and "About Item Types" to learn more about creating a File Browse page-level item