+1  A: 

I like everything you are doing except for the displaying all query information via the querystring parameter. I would suggest that feature only be available in debug mode on a dev. server or something of that nature. It could otherwise pose a large security risk.

I also see in that query you posted (line third from the bottom) ends in

where <some field> = 582

It would be a good idea to use parameterized queries instead of string concatenations. It leaves you open for a slew of nasty problems like slower performance and sql-injection attacks. If you use parameterized queries, that would go away.

Hope I added some value to your "standard".

Best of luck.

Artel
they are better than parametrized queries, they are using SuperOffice ORM :) that is only the output of the query for debugging information... when something is wrong and we want to see what is happening instead of call me to debug :) but I appreciate your input :)
balexandre
A: 

"If you add &debug=y to the query string I will show a debug window with all queries and procedures called"

Now, normally I'm the one to criticize security by obscurity, but this is a very bad idea. There's no reason to completely expose your implementation like this. If you have this debug option enabled on a production server, at most you should log to an internal file.

Same goes with your "helpful" traceback error message. This info is restricted for a reason.

Even the version link can be considered a vulnerability. See e.g. this Wordpress artice which advices not publishing the Wordpress version you're using due to the multitude of past vulnerabilities and the fact that people are very slow to upgrade.

Matthew Flaschen