Click here to Skip to main content
14,640,145 members
Articles » Database » Database » SQL Server
Posted 29 Jul 2009


58 bookmarked

How Do I Protect My Stored Procedure Code

Rate this:
4.86 (36 votes)
Please Sign up or sign in to vote.
4.86 (36 votes)
29 Jul 2009CPOL
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

Comments and Discussions

QuestionVery useful for me. Pin
Member 82572448-Jun-16 2:25
MemberMember 82572448-Jun-16 2:25 
GeneralMy vote of 4 Pin
Umesh AP27-Apr-16 0:00
MemberUmesh AP27-Apr-16 0:00 
GeneralRe: My vote of 4 Pin
Md. Marufuzzaman6-Jul-16 20:02
professionalMd. Marufuzzaman6-Jul-16 20:02 
Questiongood Pin
mahendranvis10-May-15 20:22
Membermahendranvis10-May-15 20:22 
GeneralRe: good Pin
Md. Marufuzzaman11-May-15 4:43
professionalMd. Marufuzzaman11-May-15 4:43 
QuestionNice Pin
Sibeesh Venu4-Aug-14 18:13
professionalSibeesh Venu4-Aug-14 18:13 
AnswerRe: Nice Pin
Md. Marufuzzaman4-Aug-14 21:23
professionalMd. Marufuzzaman4-Aug-14 21:23 
GeneralMy vote of 5 Pin
Sibeesh Venu4-Aug-14 18:12
professionalSibeesh Venu4-Aug-14 18:12 
GeneralRe: My vote of 5 Pin
Md. Marufuzzaman4-Aug-14 21:22
professionalMd. Marufuzzaman4-Aug-14 21:22 
QuestionOrignal Article Pin
santosh panchal17-Dec-13 20:36
Membersantosh panchal17-Dec-13 20:36 
GeneralRe: Orignal Article Pin
Md. Marufuzzaman4-Aug-14 21:21
professionalMd. Marufuzzaman4-Aug-14 21:21 
GeneralMy vote of 5 Pin
macsys1-Sep-12 19:41
Membermacsys1-Sep-12 19:41 
GeneralRe: My vote of 5 Pin
Md. Marufuzzaman4-Aug-14 21:21
professionalMd. Marufuzzaman4-Aug-14 21:21 
GeneralMy vote of 5 Pin
Manoj Kumar Choubey17-Apr-12 2:30
professionalManoj Kumar Choubey17-Apr-12 2:30 
GeneralRe: My vote of 5 Pin
Md. Marufuzzaman4-Aug-14 21:20
professionalMd. Marufuzzaman4-Aug-14 21:20 
GeneralMy vote of 2 Pin
Member 27506653-Mar-12 22:03
MemberMember 27506653-Mar-12 22:03 
GeneralOriginal article Pin
rparrales32126-Aug-10 9:58
Memberrparrales32126-Aug-10 9:58 
GeneralRe: Original article Pin
Md. Marufuzzaman26-Aug-10 19:58
professionalMd. Marufuzzaman26-Aug-10 19:58 
GeneralSecure one Pin
thatraja15-Jan-10 22:20
professionalthatraja15-Jan-10 22:20 
GeneralRe: Secure one Pin
Md. Marufuzzaman15-Jan-10 22:31
professionalMd. Marufuzzaman15-Jan-10 22:31 
Generalgood job Pin
Rajesh Naik Ponda Goa12-Oct-09 2:29
MemberRajesh Naik Ponda Goa12-Oct-09 2:29 
GeneralRe: good job Pin
Md. Marufuzzaman12-Oct-09 3:26
professionalMd. Marufuzzaman12-Oct-09 3:26 
GeneralGood Article but one thing Pin
percyvimal29-Jul-09 23:21
Memberpercyvimal29-Jul-09 23:21 
GeneralRe: Good Article but one thing Pin
Md. Marufuzzaman30-Jul-09 7:21
professionalMd. Marufuzzaman30-Jul-09 7:21 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.