Security

• Form Method Spoofing
• Session Security
  • Cookies Encryption
  • Session Config

Your app, by the virtue of being a public facing web application, needs to be secure by default. As a web developer you should be aware of most, if not all, security measures that you need to take to minimize the risk of getting your web apps compromised. While this is ideal, the reality is that it is a daunting task to know and implement all the security measures, even for a seasoned web developer.

Alpas comes with many security measures already in place to make sure you spend as less time as possible worrying about the security and so you can focus on delivering an app that your users love and trust.

/alert/Alpas does its best to implement security measures out-of-the-box to make your web app as secure as possible. However, the responsibility lies on you to make sure you have secured all the borders as far as the security of your app is concerned.

Let's talk about some ways you can keep your app more secure and few things that you just need to be aware of.

Form Method Spoofing

HTTP forms only support GET or POST but not PUT, PATCH, or DELETE. To use these methods in your form so that the correct route gets matched, you need to spoof it by passing a hidden field named _method with your form.

For your convenience, Alpas also comes with a {{ spoof() }} view function that you can use to create the hidden field for you. spoof() takes the name of the method you want to spoof — one of PUT, PATCH, or, DELETE methods.

<form action="/docs" method="post">
    {{ spoof('delete') }}
    {# <input type="hidden" name="_method" value="delete"/> #}
    <button type="submit">Delete</button>
</form>

Method spoofing is enabled by default. But, you can disable it by setting the allowMethodSpoofing property to false in your AppConfig class.

Session Security

Session is a very critical component of any web application in terms of both the functionality it brings to the table and the security risk that gets tagged along with it. Session is the magic sauce behind making the stateless nature of web work as if it is not stateless.

Cookies Encryption

When a browser makes a request, your web app makes a session and attaches an id to the response it sends back. This id is saved by the browser as a cookie and, as long as they are not expired or deleted, sends it back to the server in every subsequent requests. The web app uses this id to lookup the client's info and identifies the client as a guest or as a "known" user.

As you can imagine, a little mishandling of these sessions and cookies could leak your sessions and make your web app prone to session hijacking among other threats.

Alpas encrypts all your outgoing cookies by default and decrypts as soon as it receives them to make it totally transparent to you. The encryption is done using APP_KEY key defined in your .env file. You want to keep this key very secret by not sharing with anyone and definitely not pushing it to your version control system. All your team members can have their own unique app keys and the app will work just as fine.

/tip/ You can quickly create a new app key by running alpas make:key command.

In case you want to skip encrypting some outgoing cookies, you could return a list of their names from SessionConfig's encryptExcept property.

Session Config

You can extend dev.alpas.SessionConfig and tweak it as per your requirements. The default values are set conservatively preferring security over generosity. Consider the following suggestions when making the changes: