URGENT : API exposing entire SQL query despite Debug Mode is turned Off

Hi Me again!!
Wappler 6.8.0 Using Node server.

I have turned Off the Debug mode yet the API returned the entire SQL query. Is there any way to stop this from happening?

Hi,

You should share a screenshot of the relevant Wappler steps so one can attempt to find what step is the culprit for throwing the query like that

Do you have any Response step?

You may have already checked but the Debug Mode setting is target specific - switch to the development target and check the setting again

Make sure debug mode is off in server connect global settings and also make sure the debug option is also off for the database query step.

Yes, both debug options are off(BTW the query being displayed is a paged query that do not show the checkbox for debug). I want to point out that I tried searching %00 and the error is invalid byte sequence for encoding "UTF8": 0x00. Does the search string play any role in this?

If both are off this won't appear.
Please make sure the debug is off for this specific target and that the config file is uploaded to the server:

Screenshot 2024-09-17 at 19.13.38

debug should be off in this file uploaded on the server.

I work only on development target, do not have any other target.

I do not have any response step. Just the output of the query is turned on.

Debug mode is off on the global settings. It's a paged query so can not turn on or off the debug mode on it. Config.json has "debug": false, and is present on server as well.

Just to add: The query is already in Try Catch block.

@Teodor It's a big GDPR issue, raised by a pen tester for my client. Can you please have a look at it?

When debug is false it should always output 'A server error occured, to see the error enable the DEBUG flag.'. You can also add a custom 500 page to your project where you can have your own message Creating Custom Error Pages in NodeJS.

Yes, but this is not happening. I have checked multiple times, the global debug mode is off and still it is throwing this error. I know this always happens but specifically in this case where I try to pass
"%00" as parameter to query it is failing and returning the entire query.

The exception here is from some core Wappler code, and not from the DB query step.
There SA itself has try-catch block, and the query is inside it.
Its not even going in the catch block.

http://localhost:3000/api/employee?offset=0&limit=10&search_string="%00" 

This is how the SA is being called from the browser URL. The passed param %00 is the reason for the weird error - which is not even being caught by the try-catch block.

Hi Patrick,

As mentioned by @sid too, this is a major issue for everyone using Wappler. All the apps developed using Wappler will fail cybersecurity test - The passed param %00 is the reason for the weird error - which is not even being caught by the try-catch block.

This has been raised as a red flag in our pen testing report and we need to resolve this before Friday otherwise all our clients wont be using the app developed and we will be losing the contract.

Any suggestion/update here will be greatly appreciated.

Any update on above?

Which database driver do you use? It almost looks like the database driver returns the error as a valid response instead of throwing a javascript error. If you check the source of the response, does it return a json or just plain text?

Even if an error is in another module that was being called from an action it should catch the error unless there was another try/catch that handled it. I checked the methods that are being called from the query action and non handles errors and should throw an error on the action. Haven't checked the 3rd party packages like knexjs and the used database drivers which I will check next.

Its going to sound a bit stupid and I'm sure you have tried it but try to completely delete the container locally then make sure that what you update has debug turned off then recreate.

I'm not saying that is the cause and it may be the internal code but a lot of times I get server settings that I think are changed like this that seem to persist until I delete the container in docker desktop then republish it.

I don't know why it just seems like that helps sometimes