Everything started in 2015, when Jb and I left Apple to co-found Sqreen, with a singular vision to democratize security. Our belief then, as it is now, is that a strong security posture can only exist when security is infused across the software development lifecycle; when it is not just the concern of security teams, but of developers and operations teams as well.

One of the more common mistakes that I see organizations make on digital security is ignoring free resources that can help their business level up. This is rarely intentional. Instead, teams simply don’t know about the resources they have available. Often, that’s because their leadership doesn’t know where to look for good information security guidelines. There’s nothing wrong with that. No one knows everything.

As cybersecurity attacks become more and more common, it’s extremely important to secure your APIs. However, some developers neglect securing their APIs if they believe their APIs are only communicating with the frontend of their programs. There is this misleading perception that a well-secured front end excuses you from paying too much attention to related API security.

Web applications are one of the most targeted assets these days because they’re both open to the internet and have a larger attack surface. Attackers find various ways to hack web applications. And among all of those techniques, some make it to the OWASP Top Ten list of security risks. Cross-site scripting (XSS) has been one of the consistent toppers of this list, and in this post, we’ll discuss in detail one variant of cross-site scripting—stored XSS.

The database is an essential part of a web application. It’s where you receive and store users’ data, which you can then use to provide personalized services. As such, database security is an important part of every web application to ensure the safety and integrity of data collected from users. In this post, we’ll be looking at SQL database vulnerabilities in Node.js, like SQL injection, and how to prevent them.

Web applications have become one of the most important assets for companies of all sizes. And due to this, they have also become a target. Web applications are getting more complex and bigger in size. This results in an increase in the attack surface for malicious actors. Bad actors are growing more skillful every day, and they use different tools and techniques to hack web applications.

If you’ve been around web development for a while, you’ve almost certainly heard the term “SQL injection” and some terrifying stories about it. PHP, like many other languages, is not immune to this type of threat, which can be very dangerous indeed. But, luckily, protecting your websites from SQL injection and other similar threats is something you can take tangible steps towards.

At Sqreen, we take training seriously. We’ve always given Sqreeners access to conferences and run community learning events in our Paris office, but, of course, the current health crisis has meant in-person events are no longer possible. To keep up our training standards during these times, and because our ProdEng team is now located in more places, we decided to run our first virtual coding dojo.

This post’s topic is very straightforward: SQL injection, Ruby flavored. More specifically, how you can protect your Ruby application against SQL injections—and other common security threats. Ruby is a wonderful language for beginner coders to start with and scale to large, distributed Web and Desktop applications. It has an accepting and helpful community. Also, it strives to keep itself up to date to match the needs of developers.

Welcome to part three of the Sqreen architecture through the ages series. In case you missed it, here is part one, and here is part two. In this third and final entry to the series, I’m going to discuss how we leveled up the Sqreen backend to handle the growing scale of users and of the Sqreen team, and the journey we took moving from a self-contained product to a proper platform. That will catch you up to the present of where Sqreen is today, from an architecture-perspective.