7 Replies Latest reply: Aug 30, 2007 6:33 AM by 423296 RSS

    Securing Source code/application

    Raviteja
      Hi All,
      Is there any way we can hide and secure apex application and its componemts, so that once installed the customer can't change them .

      Thanks in advance.
      Sam
        • 1. Re: Securing Source code/application
          423296
          Sam,
          Yours is a multi-faceted question. Does the customer have access to the database? Does the customer have access to all of the directories? Are you giving the customer admin and/or developer rights in APEX? As far as your code goes you can wrap it into plb's that will prevent them from changing that much. But if they have system privileges to the database there is not much you can do. You could set up another box with XE and APEX that you could control. It would query their data from their database. Thats the only way I can think of to really secure things.
          Keep Smiling,
          Bob R
          • 2. Re: Securing Source code/application
            Raviteja
            Bob,
            Thanks for your post. Customer will have all privs in my case since we are planning to develop a product that will be installed onto customer's databases.
            I was leaning towards APEX but securing the code is very important in our case.
            Any ideas ???
            • 3. Re: Securing Source code/application
              VANJ
              See some similar discussions at

              Re: How to conceal HTML DB app source code?
              Re: shipping code
              Re: How can I hide the code?

              But none of the solutions are really bulletproof.

              If I am not mistaken, Oracle has acknowledged this need and the upcoming 3.1 version of the product should have what you need.

              Refer to the first bullet point under the APEX 3.1 heading at http://www.oracle.com/technology/products/database/application_express/apex_sod.html

              Just a guess, I could be completely off the mark.

              Hope this helps.
              • 4. Re: Securing Source code/application
                135285
                Sam,

                as one of Vikas threads already says, put most of your product logic into PL/SQL packages.

                BTW, that's a general best practice, because
                -) editing PL/SQL code in the APEX environment isn't very comfortable
                -) PL/SQL in APEX is slower, because it has to be executed as dynamic sql, compared to a already compiled PL/SQL package
                -) putting business logic into PL/SQL packages has the advantage that you separate it from the UI layer and that you are able to also call it from other programs (eg. batch jobs, ...)
                -) and finally the biggest advantage, you can wrap a PL/SQL package, so that nobody except of the database can read the source code.

                Patrick
                ----------------------------------------------------------------------------------------------------
                My APEX Blog: http://inside-apex.blogspot.com
                The ApexLib Framework: http://apexlib.sourceforge.net
                The APEX Builder Plugin: http://sourceforge.net/projects/apexplugin/
                • 5. Re: Securing Source code/application
                  135285
                  Vikas,

                  I don't think that the new 3.1 runtime only feature is intended to secure an APEX application. What I understood, it just removes the possibility that you can edit an APEX application on a production system. But you still have the application import script in clear text, which you can load into an APEX system with developer access and there again you can read all the code...

                  Patrick
                  ----------------------------------------------------------------------------------------------------
                  My APEX Blog: http://inside-apex.blogspot.com
                  The ApexLib Framework: http://apexlib.sourceforge.net
                  The APEX Builder Plugin: http://sourceforge.net/projects/apexplugin/
                  • 6. Re: Securing Source code/application
                    cd_2
                    BTW, that's a general best practice, because
                    -) editing PL/SQL code in the APEX environment isn't
                    very comfortable
                    -) PL/SQL in APEX is slower, because it has to be
                    executed as dynamic sql, compared to a already
                    compiled PL/SQL package
                    -) putting business logic into PL/SQL packages has
                    the advantage that you separate it from the UI layer
                    and that you are able to also call it from other
                    programs (eg. batch jobs, ...)
                    -) and finally the biggest advantage, you can wrap a
                    PL/SQL package, so that nobody except of the database
                    can read the source code.
                    Plus if you use the translation feature it's easier to fix any flaw
                    in your business/transaction logic in the package.

                    C.
                    • 7. Re: Securing Source code/application
                      423296
                      raviteja,
                      Besides the things that were already mentioned, the only other thing I can think of (and have used) is to install a one-way key that identifies the machine that your app is installed on. That way no one can copy your app and run it at another site. The way this works is that on the first install your app must read the machine name where the app is being installed. A couple of ways to do that such as 'select machine from v$session';. Then encrypt that (using a wrapped PL/SQL procedure) and store it in a table. Create a trigger that unencrypts the item and compares that item against the machine name when the app starts.
                      Keep Smiling,
                      Bob R