Try it out yourself. Add the following query information to your Oracle Portal url and you will most probably enter the edit mode of Oracle Portal: &_mode=16. This could be a security breach or at least unwanted behaviour.
This situation can be prevented easily by adding some rewrite conditions and rules to the Apache configuration. I did this for a Telco who brought their Oracle Portal environment to the internet.
The following excerpt tries to remove the “_mode” parameter from the query information.
RewriteCond %{QUERY_STRING} (.*)\&?_mode=[0-9]*\&?(.*) [NC]
RewriteRule ^/(.*) /$1?%1%2
If the query information still contains the “_mode” parameter the (clever) user will be redirected to an error page using a direct access url:
RewriteCond %{QUERY_STRING} (.*)\&?_mode=[0-9]*\&?(.*) [NC]
RewriteRule ^/(.*) /pls/portal/url/page/versatel/versatel/errorpage
Note: Do not apply this configuration to the development environment 
.
October 4th, 2006 at 19:02:25
Eventhough its not hurting everything, I tend to add &_debug to the production rewrite rules of a portal application server as well. It will show all the mit and miss cache information. Another fun one is to set the page_id=1 which will always take you to the default portal home page unless they’ve deleted the main portal group (which is rare)
October 4th, 2006 at 21:48:50
This is another one:
RewriteCond %{QUERY_STRING} ^(.*)(&_mode=[^&]+)(.*)$
RewriteRule ^(.*)?(.*) $1?%1%3 [R]
November 20th, 2006 at 07:51:23
Eugene’s is superior… it catches encoded urls too (eg. _mode=%31%36), however, _mode= are used in portal and so should not be restricted.
I use this:
RewriteCond %{QUERY_STRING} _mode=(1|%31)(6|%36) [NC]
RewriteRule ^(.*)$ – [F] #Rewriting the rule doesn’t have the desired affect, so I just forbid it