ajax <-> database safety

No, I think I was not clear enough, my excuses.

Off course that a client can never ever define a table in a database, this function will be only for the administrator in the admin session. Also there will be different administrator roles with different permissions. Only the adminsitrator with the highest permissions can create tables. That way only the highest admin can design a table and create a form for it. I think this would be useful tool once the cms is active and there could be an unforeseen need for collecting data like a questionnaire (or something like that).

Only the form will be visible for the clients, like any other form, with client side validation and  on the server  side also validation. I use ajax forms with clientside validation to post data, but server side validation will not be neglected, since everything form clientside can be easilly manipulated by the wrong people. You don't have to be a genius to send data over the internet, so never never server side is going to be neglected.

The only thing that could be visible is the table name, not on screen, but only in the ajax post data. That is all  what they see, but as we all know, it doesn't take rocket science to read this data.

As I can think of now, this would be the most straigtforward way of creating modules and forms 'on the fly', but it worries me that the client can see the table name because I like everything on server side to be obscured as it can be.  On the other hand, many opensource cms / blog etc. have the same 'problem', maybe not in the traffic, but everybody that ever downloaded a opensource cms/blog knows al the table names. And I bet that hackers with the wron intentions studied these packages very well.

So on one hand how bad can it be as an user know a certain table name if everything else is obscured, or should I be less lazy in designing an imlementation?

I'd double that vote never to let a person have any control over the database, your business logic squarely handles all of that. You can always make them feel like they control it (table name, columns, etc) but in your back end you should just be storing those as extra table strings that only mean something to the user, not anything that correlates to anything about the actual table.

You're right to be cautious about any hints you leave in your front end about your back end. If they can read it, they will, it's a hole. Serialization, encoding, encrypting and such won't help here easier because the front end will need to know how to utilize it and therefore any developer can use that to tokenize, decode and decrypt.

Your front end should just manage the users experience and ability to work with the data, but that's where it should stop. The back end needs to sanitize everything to a fitting level.

I have moved your discussion to the Coding Corner just so that it is in a place where users with similar questions can access it.

Ben is right that the coding forum is the better place to post this, but a lot of coding questions come through the DW forum, too.

With a backend language like PHP or Coldfusion you could avoid the security risks of AJAX, but there are other issues here as well.

I would never allow clients to define tables and column names in the database. Period. Never. So much could go wrong. They could use reserved words and special characters that would break the table and may seriously damage the database. You could, in theory, write code to catch all the potential problems, but I would still never go down that road.

I have created a form editor that allows clients to build up a form. They pick the input labels and the type of input (radio, checkbox, text, textarea, select) but they don't name the columns, and all the forms are records in a table I have prepared. When the forms are used, the form responses all get generically sanitized with PHP code before going into the database.

I don't use ajax at all for this. Just PHP.

Mijnheer Biesheuvel,

I noticed that you also posed the question in the Coldfusion forum. That is a good idea as this forum concentrates more on front-end coding. You may also like to try the Coding Corner, a brand new forum populated by persons that would love to discuss the problems.