CODEWITHSUNDEEP
javascriptasp.netsecurity
user3115001
user3115001

Reputation: 404

Securing HTML and JS files in SPA with .NET

I'm starting to develop single page apps with .NET and Durandal JS and I'm wondering how to secure the HTML and JS files of the application. I'm talking about the files in the App folder, those files currently can be directly accessed through the URL and I would like to prevent this.

Of course, since the HTML will be displayed anyway to the user it seems to be unnecessary to do that, but I really think it's better to have this and mainly the JS logic protected from direct access. I was looking at some examples of authentication in SPA's and mostly of them expose some of the logic used in this way.

How can I do that? How can I prevent direct access to these files? I thought on doing that with a route mapping to an action in a controller to return an error, but I think that in this way my javascript would be blocked as well.

Upvotes: 3

Views: 581

Answers (2)

Dalorzo
Dalorzo

Reputation: 20014

This is my advise:

  1. You need to use .NET Forms Authentication. This will allow you
  2. To set up your web.config like this:
<compilation ...> 
       <buildProviders>
        <add extension=".html" type="System.Web.Compilation.PageBuildProvider"/>
        <add extension=".htm" type="System.Web.Compilation.PageBuildProvider"/>
        <add extension=".js" type="System.Web.Compilation.PageBuildProvider"/>
      </buildProviders>
    </ compilation ...>

This configuration forces your html and js to be validated against your forms authentication, without loosing the wonders of the MVVM Javascript Framework.

  1. Set up the roles and permissions probably folder based, again in your web.config to secure both html and js files, like this:
<location path="js/app/folder1">
    <system.web>
      <authorization>
        <deny users="?"/>
        <allow roles="role1"/>
      </authorization>
    </system.web>
  </location>
 <location path="js/app/folder2">
    <system.web>
      <authorization>
        <deny users="?"/>
        <allow roles="role2"/>
      </authorization>
    </system.web>
  </location>
  </location>

Upvotes: 0

moribvndvs
moribvndvs

Reputation: 42497

First and foremost, trying to prevent people from downloading and inspecting client code in an application that is running on the client is an exercise in futility. If you give someone something a computer can execute within the system a person has access to, that someone can reverse engineer it, or find someone who can. More often than not, the only person who suffers from your tricks and hacks to try and prevent them is you, the developer, both in wasting time implementing something that will fail, and trying to work around it when debugging your own work.

If you are truly interested in dissuading casual attempts to peek at your work, well, alright.

You can minify assets in a way that also obfuscates, but all that does is make it temporarily inconvenient (such an approach is still valuable in reducing page weight, however). There is a plethora of tools that make it easy to de-minify code.

You could come up with a way that the initial page and script bootstraps the rest of the app by requiring it to, say, place a certain value in the header, and have your HTTP server prevent serving resources to certain files unless they have that header. But requests can be easily inspected, recreated, and issued manually to circumvent that.

Perhaps some efforts have been made to create a shell app or browser that only executes trusted code that you package up into some sort of encrypted format and can open with a key. Or perhaps a browser plugin. I don't know. You could come up with whatever crazy thing you want, but is it worth it? Will people want to use it? If you make it hard for someone to use something, they won't.

The key, then, is to minimize what you give to clients to run on their machine that you consider invaluable and/or a trade secret. You can strategize what really isn't all that special (and let's be honest, your client side code for your app's UI isn't really all that valuable... not because you didn't create something wonderful, but the code is only the means to an end) and choose the right technological approach to provide that service but keep it out of people's hands.

So if you have some special sauce for a business model, don't implement it all on the client side. Separate the concerns into client responsibilities and server responsibilities. Restrict the client to basic UI, getting info from the user, sending to the server, and displaying the response. Keep your secret sauce on the server away where they can't see it.

You don't HAVE to make it an SPA... just make it a standard ASP.NET WebForms or MVC and be done with it. If you do go with SPA, you must buy into its inherent principles.

If that's not possible, and all logic has to be on the client, you need to make a decision. Either a) don't bother b) beat your head against the way trying to construct your perfect secure little environment (which will fail) or c) rely on legal agreements with your users.

TL;DNR: My opinion? Be proud of your work and let the value of it stand on its own. Keeping private business logic on the server end and architecting appropriately, in addition to letting go of the notion that people seeing your client code will threaten your business, is a simple and sound approach. Also, minify your JS. It doesn't secure your intellectual property, but it has other more practical benefits.

Upvotes: 4

Related Questions