Since one possible application of DBIx::Recordset is its use in a web-server environment, some attention should paid to security issues.

The current version of DBIx::Recordset does not include extended security management, but some features can be used to make your database access safer. (More security features will come in future releases.)

First of all, use the security feature of your database. Assign the web server process as few rights as possible.

The greatest security risk is when you feed DBIx::Recordset a hash which contains the formfield data posted to the web server. Somebody who knows DBIx::Recordset can post other parameters than those you would expect a normal user to post. For this reason, a primary issue is to override all parameters which should never be posted by your script.

Example: *set = DBIx::Recordset -> Search ({%fdat, ('!DataSource' => "dbi:$Driver:$DB", '!Table' => "$Table")}) ;

(assuming your posted form data is in %fdat). The above call will make sure that nobody from outside can override the values supplied by $Driver, $DB and $Table.

It is also wise to initialize your objects by supplying parameters which can not be changed.

Somewhere in your script startup (or at server startup time) add a setup call:

 *set = DBIx::Recordset-> Setup ({'!DataSource'  =>  "dbi:$Driver:$DB",
			                        '!Table'	  =>  "$Table",
			                        '!Fields'	  =>  "a, b, c"}) ;

Later, when you process a request you can write:

 $set -> Search (\%fdat) ;

This will make sure that only the database specified by $Driver, $DB, the table specified by $Table and the Fields a, b, and c can be accessed.