Flash Security Model

We all know that security is one of the most important parts of any enterprise solution. That said, it's also dead boring. Deneb Meketa led this session and opened with a line very similar to that so I don't feel bad saying it. Before I get into some of what we went over in this session here is a nice video that overviews the first day and general session.

Now that you're excited let's talk security. In order to make this fairly brief I'm mainly going to just go over the five basic security rules Deneb gave us and if I think of anything for each of them I'll expound.

Rule 1: Use least privilege

When creating your cross domain files etc. never use an allowDomain="*". It may be a bit of a pain to actually enumerate the domains allowed to access your stuff but it's much better than being hacked.

Rule 2: Validate Input

You never know what someone might try to stick into the stream as input so validate it on the client side and on the server side.

Rule 3: Deploy HTTPS Consistently

Don't mix HTTP and HTTPS. All you will do is expose holes in your security.

Rule 4: Prototype Early

I thought this was an interesting rule for the Flash Security Model but as he explained a bit more it made perfect sense. If you don't prototype early there may be something you plan on doing which simply isn't allowed within the Security Model. If you prototype that stuff early and find out it won't work you may be able to find an easy way around it. If you wait until the end it may be a nightmare.

Rule 5: Keep Track of Security Changes

The last thing you want is the CEO walking up to you and saying, "Internet Explorer upgraded my Flash Player and now none of our stuff works. What did you break?" Believe me, I know.