I have asked a government agency, under Freedom of Information legislation, to release two SQL queries they ran to produce a table which they published in a report.

That is, the agency published these two tables of figures showing, for each year, the number of cases completed under various categories and some aggregated statistics for each category. I want to see the query used to generate each table, in order to see how the data was filtered and precisely how the agency defined each category.

The agency has refused my request on the basis that releasing any SQL queries will prejudice their information security.

Under the relevant legislation, I now have the opportunity to apply for a review of this decision, in which I would have to explain why the agency's reasoning is flawed.

To my mind, the only way this could possibly be a security risk is where an attacker uses the information about table and column names to launch an SQL injection attack. However, the database in question is an internal data warehouse with no publicly-accessible web applications accessing it and, in any case, the agency has strict coding standards and penetration testing, etc, for preventing things like SQL injection vulnerabilities.

I can also imagine that if the agency was, say, the US National Security Agency, and the database was called 'overseas_phone_taps_by_country', then the table/column names would themselves be sensitive information. In this case, however, we are talking about an accounting database held by a pretty boring regulatory agency.

Again if the query was one used to generate lists of cases, then I could see the issue, since the query would contain things like the threhold at which a case will be considered for enforcement action, etc. However, that is not the case here.

How could releasing the text of an SQL query be a security risk?

EDIT: The agency provided the following explanation in their refusal letter:

SQL queries contain information about the agency's information systems (information related to the content, location and storage of sensitive information), which, if released, could reasonably be expected to increase the risk of compromise to the agency's information systems.

As such, I consider that disclosure of the SQL queries represents a potential security risk to the agency.

The advice from the agency's security expert reads:

I am of the opinion that the release of the SQL queries, even in a redacted form, would provide information about the programmable interfaces and logic flow within our systems, and give information about identifiers, pointers and references that would compromise the security and safety of the agency's systems.

  • Sounds like they thought it would be easier to reject your request than fulfill it. Unless they're doing something strange like heavy processing in the query, it's likely they just forgot the query they used and can't be bothered recreating it. Never attribute to malice what can be explained with laziness.
    – Daisetsu
    Apr 24, 2016 at 7:52
  • I forgot to mention in the question, they have in fact found the two queries, they just won't give them to me. Apr 25, 2016 at 1:01
  • I have a feeling that releasing such statements puts them more in danger than giving away the query.
    – techraf
    Apr 25, 2016 at 1:19
  • I think you'd be much smarter to ask for HOW they arrived at the answers rather than directly asking for the SQL. The two are related, but subtly different. You're really after how they aggregated the data, so ask for that. It'd be much harder to argue that asking for the underlying methodology used compromises any internal security. Jun 14, 2016 at 19:41
  • @SteveSether, in this jurisdiction, I have a right to documents but not a right to information. The agency will not willingly tell me anything. Therefore I need to identify a document that already exists which contains the information I need. An alternative angle might be to ask for any specifications that were written for the person who wrote the SQL. Jun 22, 2016 at 13:07

4 Answers 4


They probably have a DBA who has been told that you shouldn't let people know the structure of the database due to SQL injection risks. As you mention though that doesn't make a ton of sense for an internal database.

There's no obvious risks to releasing a query from a security standpoint. What was their exact wording of the reason they refused it?


Generally when you are trying to secure an application you want to make sure that you aren't disclosing any information that could potentially be used as part of an attack. This is the same reason that it is more secure to display a generic error page instead of a stack trace. Even though seeing the stack trace probably isn't a vulnerability itself - it makes life easier for an attacker gathering information about the system.

This should not be confused with "security through obscurity" in which you rely on something being secret to maintain security. The assumption is that every effort has been made to secure the application in question.

It doesn't really matter whether the application is internal or not in my opinion. You routinely hear stories about hackers breaching government networks (sometimes hiding in there for years), so the fact that it's on an internal network doesn't mean it is safe from external threats.

Also having strict security guidelines and performing penetration tests doesn't guarantee 100% security either. If you talk to anyone who does pentests for a living they won't guarantee that they find 100% of security issues (and if they do they are probably blowing smoke).


Maybe would be better to just ask the agency "How the data was filtered and precisely how the agency defined each category?"

While I agree that hiding SQL to add security is just "security by obscurity", I also fail to see why providing the SQL queries would be the best way to provide the information you need or claim to need.


They could easily substitute the actual table and column names with aliases. However, from a security perspective, even a completely unredacted SQL query is unlikely to release any information that would be useful to an attacker. Once an attacker gains dba level access to the database, querying the schema is trivial. The reverse is not true.

  • What if they don't have DBA level access? Then this information would be useful wouldn't it? Jun 14, 2016 at 21:41
  • Knowing a small subset of the schema is moderately helpful in a sql injection attack, but if the system is that vulnerable, an experienced attacker wouldn't need that information. The sql for one query just isn't likely to give anything useful that a skilled hacker couldn't obtain directly. Further, no hacker is going to go with a FOIA request and leave a paper trail. Jun 15, 2016 at 1:10
  • How likely is it that an attacker can get into an account that can query the contents of a table but not its schema? Jun 22, 2016 at 13:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .