A Web Developer’s Blog
I am working on an application that needs to be able to login to a Laravel instance via API.
In my usual workflow all the session management and XSRF protection has been automagical but I needed to be able to build a test case - and all the docs seemed to assume it would “Just Work™”
Read more ...JWT uses secrets which are stored securely
This secret is used to sign (opr encrypt) the token - and then the token can be validated using this secret. If the secret is shared between multiple servers - the token can ba validated on any of them.
The secret can change over time (at which point any previous tokens expire) and should be different in each environment eg there is no need to have the same secret in staging and production as token should not be valid across these.
It hasn’t been especially clear to me how a new token is best generated.
Read more ...Since LastPass’ most recent security issues (do use a password manager but not LastPass) I’ve seen a lot of people online changing all their passwords and realising how bad the experience is.
For those of us with names which can be spelled in the limited ASCII alphabet the pain point is the password part - where the rules can be annoying but in the end we can work around them.
Today I saw a post Hello my name is St�phanie which highlights how there is a bigger problem for many people.
It all got me thinking : why do we (developers) do this ?
Read more ...
Laravel has some really good features for setting database connections - but oddly this isn’t spelled out in the documentation.
Databases (especially in Docker containers) often come by default with a single, powerful, user account.
As a result all too often people run Laravel without considering the principle of least privilege.
By following a few simple steps we can enhance security.
As web developers we are used to people mostly using teh websites we build in teh way intended.
It can be hard to get into the mindset not just of what can go wrong but how what we have built can be subverted.
There are a lot of tools available to those who want to attack our websites - and I think it is worth web developers having some familiarity with these.
The tools themselves are legal - but should only be used where you have permission.
Read more ...As an industry we have to do better.
First we need to study common issues, security standards and processes.
It also helps to try a little ethical hacking to see things from the other side.
Most of what you read about securing PHP is how to write secure code - and that is really important.
In addition it helps to setup PHP on the server for best security.
There is plenty we can do to harden the setup without hurting the functionality we need.
The more layers we have in our security setup the better.
I’m staring a new PHP project and I wanted a clean docker image to work from.
I inherited one on my last project and wanted to improve image size, security and production alignment.
I love the extra security CSP brings - but it’s still a bit new to me and I hadn’t setup reporting because this is a static site and I didn’t think I had anywhere easy to send the errors.
However I use Sentry for another project and realised that it offers easy CSP reporting.
Read more ...