RE: Security issues exposing database SID?

I would suggest that you provide a standard table with public read only in each database and/or database instance that has a code to publish and maintain an all databases master table in your support repository so that you don't have to publish anything even vaguely hackable.

That's either 1 row 1 column or "the number of instances" rows and two columns (the second being a match to the instance identifier) for each deployment, with a matching record in your central support database for each deployment, presumably with your deployment identifier.  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of McPeak, Matt (Consultant)
Sent: Wednesday, April 03, 2019 3:15 PM
To: oracle-l_at_freelists.org
Subject: Security issues exposing database SID?    

We are considering exposing a webservice both internally and externally.  

For support reasons, we would like the response payload to include the database SID that the service is connected to. This makes it easier for us to debug issues in development environments where systems and services are not always pointing where they should be.  

However, since the service may be exposed externally, we are concerned about the security ramifications of having our database SID known to the world.  

1. What are the security risks of exposing your SID, if any?
2. Would using DBID (i.e., v$database.dbid) be better?

--
http://www.freelists.org/webpage/oracle-l