You can see on the Community Forum that there is no session id in the URL. But that is actually an ugly hack:

    if (!inPWA()) {
       let orgUrl = new URL(window.location);
       window.addEventListener('DOMContentLoaded', (event) => {
           window.history.replaceState({}, '', `https://forums.oracle.com/ords/apexds/post/session-in-url-causes-problems-in-saved-bookmarks-6474${orgUrl.hash}`);
       });

You still see the original URL briefly when the page loads.

Hi Philipp,

Did you have a look at Rejoin Sessions?

https://docs.oracle.com/en/database/oracle/apex/24.2/htmdb/manging-instance-security.html#GUID-C676EF2F-2939-4EC3-9385-8FAEA99C8971

@menno.hoogendijk 

Hi Menno,
Yes, this solves part of the issue. But my main point is that having the session ID in the URL is more harmful than helpful. And I think rejoin session will put the session ID back after rejoining, right?

You could use Rejoin Sessions only on public pages for public facing apps. I believe it will not put the session ID back as long as you stay on public pages. 

Having the session ID in the URL is actually not harmful and improves app security as explained in the doc:

While supporting session joins is convenient, it does present some serious security risks:

Triggering malicious session state changes or other modifications.

If an attacker tricks the user into clicking an application link, this can trigger malicious session state changes or other modifications. Because of this risk, APEX requires a checksum that the attacker will not be able to guess when processing requests that alters data.

Triggering unintended changes between applications.

If a user has two applications open in separate tabs on the same APEX instance, one application could trigger unintended changes in the other one. The attacking application could be written by a hacker or it could have an XSS vulnerability that enables an attacker to inject code. This application could use Ajax calls that simulate user interactions with the other application.

Thanks @menno.hoogendijk for you explanation!

@menno.hoogendijk 

Thanks for your response! I just tested the “Rejoin Sessions - Enabled for All Sessions” option. I also set “Page Access Protection” and on the item level to unrestricted.

• It actually does not set the session ID in the URL when no page item is passed via the URL (great! )
• If you want to set a page item via the URL, it requires the session ID. If I remove the session parameter and reload it will redirect me to the log-in page so actually not rejoin.

Looks like a bug or am I misunderstanding how it should work? 

APEX requires a checksum that the attacker will not be able to guess

Completely agree. But you can pass the checksum without having to pass the session ID. The session secret is still in the cookie.

For the second paragraph I don't understand what this has to do with having a SID in the URL.

And I want to again point out that APEX is different from all other web applications I know. Banking websites, social media, etc., of course, also use sessions, but only store the information in the cookie and not additionally in the URL.

Not sure why setting an item requires the session ID. This works fine for me:
https://apex.oracle.com/pls/apex/r/citiest/public-app/home?P1_NEW=test

Another workaround is to use the x01 and grab that value to populate your page item:
https://apex.oracle.com/pls/apex/r/citiest/public-app/home?x01=lalalala

I think the second paragraph is about invoking an Application Process by name for example. The second app is capable of generating valid URLs for the first app because there is no SID.

I'll forward your questions to the team to check if they can provide more detailed answers.

The reason for having a session ID in the URL is because APEX can be run in a hosted environment. Consider apex.oracle.com. You and I both have workspaces on a.o.c. If you are currently running your application on a.o.c, and then you run my application on a.o.c, it is likely that your application session cookie(s) will get sent on your request to my application. If I can access your session cookies and your application does NOT require a session ID in the URL, I can use your session cookie information to hijack your application session.

If you have complete control over the application server and all associated applications, you don't need a session ID in the URL. If there is a chance someone (like me) could access this information (e.g. in a hosted environment), you need the session ID in the URL.

Awesome @anton nielsen that makes totally sense for me 😌

Thanks for the detailed explanation @anton nielsen . That makes perfect sense and is something I hadn't fully considered.

I still think it should be possible to get rid the SID in the URL (for people who want it, not everybody):

1: You can scope cookies to a specific path. And with the new URL syntax you have the workspace name in the URL. So APEX could create a cookie for a.o.com/…/**philipp** which will be sent to a.o.com/…/**philipp**/app/page but not a.o.com/…/**anton**/app/page.

2: There could be an environment setting in internal to enable/disable having the session in the URL like with persistant auth. And it should be disabled by default.

Taking advantage of the fact that you are talking about session and urls. When you copy your current url, close the browser ( without closing the session) then open a new browser, paste the url , the session is comming back …that behaviour is normal? can we prevent it? thanks

@philipp hartenfeller , I definitely want to be able to remove the SID from the URL…I want this feature for sure. But I still think in a shared/hosted environment you will continue to want to have it in the URL. Even with friendly URLs the APEX engine calls URLs that do not include the friendly URL path. Any time you submit a page it constructs a request to a URL like this:

https://apex.oracle.com/pls/apex/wwv_flow.accept?p_context=random-tests/emp-form/3864459571157

Could they rewrite APEX to construct a URL with the full friendly URL path? Probably…but I suspect it's a big lift and may have other security implications. I think in an environment where you do not have full control of the server associated with the host name, the URL should contain the SID.

But…most of us work in environments where we do have that control. In that case, I absolutely agree…ditch the SID from the URL.

@marcelo osorio kosky That will not (should not!) happen if you completely exit your browser and do not re-open previous sessions when you re-launch your browser. Browsers have become “smart” enough to retain session cookies and bring session back to life on a restart (if you indicate you want them to).