Is it safe to reveal table column names in ajax?

Question

I have a table like...

THINGS_TABLE
============
thing_key           int              PRIMARY KEY
thing_num           varchar(20)
thing_title         varchar(20)
thing_description   varchar(20)

And some ColdFusion (server-side code) functions that can add, edit and delete from this table. For example a createThing function might look like this in ColdFusion. The cfqueryparam parameters in the cfquery should prevent SQL injection, so I don't think SQL injection is something I need to worry about.

<cffunction name="createThing" access="remote" returntype="void">
    <cfargument name="thing_num" type="string" required="yes">
    <cfargument name="thing_title" type="string" required="yes">
    <cfargument name="thing_description" type="string" required="yes">

    <!--- write to db --->
    <cfquery name="createThingQuery" datasource="my_datasource">
        INSERT INTO THINGS_TABLE (thing_num, thing_title, thing_description) values (   
        <cfqueryparam cfsqltype="cf_sql_varchar" value='#thing_num#'>,
        <cfqueryparam cfsqltype="cf_sql_varchar" value='#thing_title#'>,
        <cfqueryparam cfsqltype="cf_sql_varchar" value='#thing_description#'>)
    </cfquery>
</cffunction>

Is it safe to reveal the actual column names in ajax calls that run the server-side code? For example, an ajax call that might look like this:

$.ajax({
    type: "POST",   
    url: "thingFunctions.cfc",
    data: { method : "createThing",
            thing_num : "the number",
            thing_title : "the title",
            thing_description : "the description"
            }})

This ajax makes it really obvious what the actual column names are in the database, and it is certainly possible for my ColdFusion function to use different argument names, but is there actually any advantage to use different names? It seems to me like it might just make the code more confusing for a developer to read, without providing any advantages from a security standpoint.

Also, perhaps there are other issues with using ajax calls like this that I'm not thinking of? I.e. a user maybe could edit the page JavaScript and call my ColdFusion code in ways it wasn't originally intended?

Answer 1

Not providing a direct mapping to column names is obfuscation. Security through obfuscation should not be relied on, but it does help, if only a little. As you point out, though, the question is to whether the tradeoff in obscuring these names is worth the extra maintenance burden. This is a matter of opinion, but I tend to say it isn't - even from a strictly security perspective, more obvious code is code that's less likely to have security issues.

Also, perhaps there are other issues with using ajax calls like this that I'm not thinking of? I.e. a user maybe could edit the page JavaScript and call my ColdFusion code in ways it wasn't originally intended?

An attacker can always modify anything on their own client. This is a fundamental point of web security.

I don't know ColdFusion enough to really understand what's going on in your example, but it looks like an attacker can just feed values into an endpoint to create new rows in your table. Should only certain types of users be able to do that? If so, you better put some authorization and authentication on the endpoint. Will there be problems if the table gets really large? Enforce per-user and per-IP rate-limits, and create an alert when the table reaches warning and critical levels.

Answer 2

I would agree with Xiong that obfuscation of table column names makes your code more complicated, and harder to understand. If you do this with every table, you might confuse other developers (or yourself, looking at the code a year later).

(I assume that your database is not directly reachable from the internet, but only through your own backend. If it is, you should review your architecture.)

Also, perhaps there are other issues with using ajax calls like this that I'm not thinking of? I.e. a user maybe could edit the page JavaScript and call my ColdFusion code in ways it wasn't originally intended?

Be always prepared that your API might not only be called from your own web page, but also from a curious developer, trying it out for fun, after having looked at the JavaScript code or HTTP traffic:

• You should always validate user data before persisting it. Otherwise you might end up fixing data causing exceptions somewhere in your backend (e.g. trying to parse a string as date, but having just a garbage string value).
• If your API route causes database rows to be added, it should probably only be available to authenticated users.