Click here to Skip to main content
977 members
Click here to Skip to main content
Add your own
alternative version


Posted 12 Apr 2012
Licenced CPOL

How Do I Protect My Stored Procedure Code

, 12 Apr 2012
Rate this:
Please Sign up or sign in to vote.
This article will demonstrate the best practice to protect SQL server code object.


Every developer is exceptionally concerned about how she/he can formulate the best security of her/his SQL code object like a view / storedProcedure as well. For this reason, we will go for encryption. Encryption is a good but not utterly tenable process. In this article, I would like to show you some best practices to protect SQL server code object.

Don't Encrypt Unless Absolutely Necessary

When you distribute SQL Server-based applications to customers and other third parties, you may be tempted to encrypt the source to your stored procedures, functions, and similar objects. Obviously this protects your code from prying eyes and keeps people from making changes to your code without your knowledge.

That said, unless you have real concerns about confidential or proprietary information being stolen, I recommend against encrypting your SQL Server objects. To me, encrypting SQL Server objects is usually more trouble than it's worth. There are a number of disadvantages to encrypting the source code to SQL Server objects. Let's discuss a few of them.

One, encrypted objects cannot be scripted, even by Enterprise Manager. That is, once a procedure or function is encrypted, you cannot retrieve its source from SQL Server. The well-known but undocumented methods of decoding encrypted source in earlier versions of SQL Server no longer work, and other methods one might discover are not supported by Microsoft. To make matters worse, if you attempt to script an encrypted object via Enterprise Manager using the default options, your new script will have a DROP statement for the object, but not a CREATE. Instead, all you'll see is a helpful comment informing you that scripting encrypted objects isn't supported (whereas, obviously, dropping them is). If you run this script, your object will be lost. It will be dropped, but not recreated.

Two, encrypted objects cannot be published as part of a SQL Server replication. If your customers set up replication operations to keep multiple servers in synch, they'll run into problems if you encrypt your code.

Three, you can't check encrypted source code for version info (such as that inserted by a source code management system). Because customers can load backups that may reinstall an older version of your code over a newer one, it's extremely handy to be able to check the code for version info on the customer's server. If your code is encrypted, you can't easily do this. If it's not, and if you've included version information in the source code, you should be able to easily determine the exact version of an object the customer is using.

How Do I Protect My Stored Procedure Code?

When deploying applications to a client's server(s) or to a shared SQL Server, there is often a concern that other people might peek at your business logic. Since often the code in a stored procedure can be proprietary, it is understandable that we might want to protect our T-SQL work. There is a trivial way to do this in SQL Server, instead of:

     SELECT 'SQL statements'


You can use the WITH ENCRYPTION option:

     SELECT 'SQL statements' 

Now, before you do this, make sure you keep the logic of the stored procedure in a safe place, since you won't have easy access to the procedure's code once you've saved it.

Now you will notice that when you try to open the procedure in Enterprise Manager's GUI, you will receive the following error:

Microsoft SQL-DMO 
Error 20585: [SQL-DMO] 
    Encrypted object is not transferable, 
    and script can not be generated. 

And when you try to use sp_helptext to review the code...

EXEC sp_helptext 'Example' 

... you will get the following error:

The object comments have been encrypted. 

Unfortunately, there are at least two ways to defeat this mechanism. One is to run SQL Profiler while executing the stored procedure; this often can reveal the text of the procedure itself, depending on what the stored procedure does (e.g. if it has GO batches, dynamic SQL, etc.). If they miss the initial install, the user can delete the stored procedures or drop the database, start a Profiler trace, and ask you to re-create them (in which case they will capture the CREATE PROCEDURE statements). You can prevent Profiler from revealing the text to snoopers by embedding sp_password in the code, as a comment:

     SELECT 'SQL statements' 
    -- comment: sp_password 


For more about this topic can be found at this link.


I hope that this article might be helpful to you. Enjoy!


  • 30th July, 2009: Initial post  


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Sean Ewington
Technical Writer CodeProject
Canada Canada
Sean Ewington is the Content Manager for CodeProject.

His background in programming is primarily C++ and HTML, but has experience in other, "unsavoury" languages.

He loves movies, and likes to say inconceivable often, even if it does not mean what he thinks it means.

You may also be interested in...

Comments and Discussions

-- There are no messages in this forum --
Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
RA-Web1 | 2.8.181114.1 | Last Updated 12 Apr 2012
Article Copyright 2012 by Sean Ewington
Everything else Copyright © RootAdmin, 1999-2018
Layout: fixed | fluid