As a developer who's been in the trenches for years, I've seen my fair share of security mishaps. From new firewall rules unexpectedly taking out the API to the dreaded "it works on my machine" scenarios, these experiences have shaped my approach to application security. Today, I want to make the case for why we, as developers, need to take ownership of our applications' security.

The Evolution of Security in Development

Traditionally, security was often an afterthought in the development process. We'd build our apps, throw them over the wall to ops or the security team, and hope for the best. But as our industry has evolved, so too has our approach to security.

The shift-left movement in DevOps had already pushed us to consider operational concerns earlier in the development cycle. Security was the natural next step in this evolution, and while DevSecOps emerged as a concept to bridge the gap between DevOps and security teams, it often fell short in practice.

What we really needed was a fundamental shift in how we, as developers, think about security. It's about ingraining security consciousness into every line of code we write, every architecture decision we make, and every feature we implement. This shift empowers us to create more robust, secure applications from the ground up.

The Power of Context

One of the most compelling reasons for implementing security at the application level is the rich context we have access to. Network-level security measures are essential, but they lack insight into the nuances of our application logic.

Consider rate limiting. At the network level, it's often a one-size-fits-all approach. However, within our application, we can make nuanced decisions:

function getArcjetClient(user) {
    let max = 100;
    if (user.isPremium) {
        max = 1000;
    }
    return aj.withRule(
        fixedWindow({ mode: "LIVE", window: "1m", max })
    );
}

This approach allows us to align our security measures with our business logic, providing a better experience for our users while still protecting our systems. If you're curious about implementing such context-aware security measures, the Arcjet Security Challenge offers hands-on experience with these concepts (and currently has a contest going until August 11, 2024).

Testability: A Developer's Best Friend

One of the most significant advantages of application-level security is testability. When security rules are part of your codebase, they become as testable as any other function. This integration allows us to catch security issues early and ensure our protection measures work as expected across all environments.

📖 Check out our article on “How to implement functional testing of security rules”

But how do we actually test security rules? We've put together a comprehensive guide on how to implement functional testing of security rules. This guide covers practical approaches to testing various security measures:

For Shield (our request analysis component), you can simulate suspicious behavior by sending requests with a special header.
Rate limiting tests involve sending more requests than the configured limit and verifying the correct responses.
Bot protection can be tested by mimicking automated client behavior, such as using a curl User-Agent.
Email validation tests should include checks for both syntax and domain validity.

Imagine being able to write tests like this:

describe('Rate Limiting', () => {
  test('allow 100 requests per minute for free users', async () => {
    // ...
  });
 test('allow 1000 requests per minute for premium users', async () => {
    // ...
  });
});

This approach allows you to automate security rule testing as part of your regular test suite, ensuring that your protection measures remain effective as your application evolves.

By making security testable, we're not just writing secure code - we're verifying its effectiveness at every step of the development process. This leads to more reliable security measures and fewer surprises when deploying to production.

Real-World Benefits

Since adopting this approach to security, I've observed several tangible benefits:

Faster development cycles: Security changes can be made and tested alongside feature development.
No more surprises in production: With comprehensive testing, what works in staging is much more likely to work in production.
More nuanced protection: We can apply different security rules based on user types, endpoints, or even time of day.
Improved collaboration: Security becomes a shared responsibility, fostering a security-aware culture across the development team.

Balancing Act: App-Level and Network-Level Security

It's important to note that application-level security doesn't replace network-level protections. Instead, it complements them. Network-level security is still crucial for access control and large-scale volumetric DDoS attacks.

The key is to leverage both: use network-level security for generic protection, and application-level security for nuanced, context-aware decisions.

Getting Started

If you're convinced and want to start incorporating security into your development process, here's my advice:

Start small: Choose one aspect of security, like rate limiting or bot detection, and implement it in your code.
Leverage existing tools: Libraries like Arcjet provide battle-tested implementations of common security patterns, giving you a solid foundation to build upon.
Make testing a priority: Write automated tests for your security rules. Try to break them. You'll be surprised what you find.
Collaborate: Involve your entire team in security discussions. It's a collective responsibility.

Conclusion

Taking ownership of application security isn't about replacing other security measures or teams. It's about leveraging our unique position as developers to create more effective, context-aware security solutions.

By bringing security into our codebase, we make it an integral part of our development process. We gain the ability to create more nuanced, testable security measures that align closely with our application's needs.

In an era where cyber threats are constantly evolving, this approach allows us to be more responsive and adaptive. It empowers us to not just write code, but to write secure code.

Remember, every line of code we write is potentially a security decision. By owning application-level security, we're taking responsibility for the safety and reliability of the systems we build. And that's a responsibility worth embracing.

If you're ready to take the next step in owning your app's security, why not sign up for a free Arcjet account?

Why Developers Need to Own App Security