Automating app development the secure way: Velocity meets defense in depth

Good afternoon. I hope you're enjoying day two of Cloudflare Connect. My name is Chris. I'm a customer engineer based out of London, usually, so I help customers be faster and safer on the Internet. 4,000 applications. Anyone guess the relevance of that number? You might have heard it a few times over the last couple of days. So there were 4,000 applications that were created from scratch, over 30 days, by Cloudflare's own people. So these are people in finance, HR, sales, marketing, not just engineering people. Just a quick show of hands, who's built something? Everyone's hand should go up for this question. In the last year or so with an AI assistant. And no, well, your hands aren't up. Keep your hands up if the thing that you built spoke to a service in production. So an API, a database, system of records. Okay. It's quite a few hands up. So this is really what the focus of the talk today is about. So one of those applications that got built by Cloudflare was built by one of my colleagues in sales. They built what they call a super app. They're very proud of it. And they just asked for a few keys to production servers for the app to do what it needed to be able to do. Yeah. Just a couple of API keys. So we wrote a blog about this recently. And the application itself is the easy part. We can all write applications with AI coding systems. We can get them running very, very quickly. And thanks to Cloudflare, deployed very, very quickly as well. But now we've got a potentially, you know, with the five minutes that it took us to write code this application, this is now a production live service, maybe even on the Internet, that has to defend itself against the rapidly changing threat landscape on the Internet. So the next 15 minutes or so, I might get short and sharp, we're going to deploy a couple of apps onto Cloudflare. So quick prayers to the demo gods. So both the live demo and AI agent coding. We'll watch them go into production, watch them go live. We'll give them production API keys. And I'll show you some things to watch out for. And some design patterns that you may want to consider when your teams are doing this. So a quick note on scope. Broadly speaking, there's two types of applications, right? You've got private, internal applications. And generally speaking, these are kind of easier to defend because we've got some really great sassy and Zero Trust tools at Cloudflare and elsewhere. And these can simply be protected by, you know, block everything unless they are an authorized user with a corporate device and so on and so forth. All the usual sassy tools that you can use on Cloudflare or elsewhere. Then you've got public applications, which is really what we're talking about today. So these applications need to sit on the Internet. They need to be accessible by anonymous traffic. They need to service this Internet sourced traffic. So we know that the Internet is a very dangerous place. And these applications need to be able to defend against this evolving threat landscape. So let's jump into the Cloudflare dashboard then. So you're looking at the worker's home screen. Hopefully that's nice and big that you can see that. This is the worker's home screen. On the right hand side, you have Agent Lee. If you haven't played with Agent Lee, I highly recommend you do. Agent Lee is Cloudflare's dashboard native agent. It can do things like add graph rules, report on security analytics and traffic analysis. It can modify CDN policy. But Agent Lee can also deploy workers applications to Cloudflare, which is really good. So I'm just going to paste a predefined prompt in here and get this whirring away while I talk. So imagine the scenario. We're a company. We've got a production API server. It's protected by an API token. And this server is a one -time PIN server. So we have a requirement to generate one-time PINs. And the demo gods are not on my side today. So let's just try this again. So our one-time PIN, our production API server is properly authenticated. It has the authentication in place. You need an API key to connect to it. And our requirement, we've given a task to one of our developers to create a nice, shiny new front end for this. Oh, this is great, isn't it? The amount of times I've practiced this and it's been perfect. Anyway, so let's keep this going. I'll just try a different way. We're going to deploy a nice, shiny front end for this production server because we want to update our customer experience. We want to align it with our brands. It's just an example, but we want to create a front end that connects to a backend service. Wow, this is great. So I have prepared for this. I'm not sure whether it's my Internet connection or the Wi-Fi or what, but it was working great earlier. Let's try one more time. If not, we'll go to the fallback plan. Okay. So the plan was to get agent lead to deploy a nice, shiny application on the Cloudflare and demonstrate how quickly and easily you can get applications running on Cloudflare. Doesn't look like that's going to happen, unfortunately. What we'll do is we'll go back to the one I made earlier down here. So this was one I deployed before. It's exactly the same idea. I gave it a prompt. I said, I'll show you the prompt. It just says, build a workers application called sign in. It serves a simple page. It takes a phone number as an input, and then that gets sent off to the API. The important thing here is it's sending a post request, giving it the formatting of the JSON to do the post. It's just sending a request to our production API server. And then importantly, I've given it the API key down here. So here's the API key. Send it as a header. And I'm doing it properly. I'm storing it as a secret. I'm not just putting it into the application hard -coded. I'm storing that API key as a worker secret. So in theory, no one should be able to get, and there's a key there. I'll delete that pretty quick, but that's the key. So I've given the agent the key. And this is what happens all the time is people are giving agents keys to things, goes into an application, which the Internet facing. So add a QR code as well. So if we just do this, so I can show you as if that had gone, if that had deployed, this is what you would see. Before I show you that actually, this is the dashboard. So this is the stats dashboard of our production API server. This is just showing us how many texts we've sent today. The production API server sent today. The way this works is our server talks to our vendor and that vendor sends text messages to our customers. We've got pay for that, right? So we kind of care about this a little bit, but we need to provide this service. So we've sent 35 text messages today. If we go back to the dashboard, I've deployed the service. You can scan the QR code. This is the thing that was deployed by the agent. It just takes a phone number. We can check that it works. And there we go. So we had 35 there before. I've sent a few more codes there through. So in theory, we should see 37, 38. That's going up very quickly. Did somebody happen to scan that QR code just now? So that was flooding me with traffic. Have we got a bad actor in the room that's just decided to attack my service? No? So I think what's happening here is this is a SMS pumping attack. So if you don't have SMS pumping, what bad actors can do is they'll go away and they'll register a very expensive premium rate phone number and they'll enter into a revenue share with the operator, the telco. And in return for generating traffic to that phone number, the bad guys will take a cut of that revenue. Unfortunately, it's quite a common thing that we see. And I think this is what's going on here. Someone in the room has decided to launch an SMS pumping campaign against my brand new application that I secured quite well. I put API keys in a worker's secret. But really, all I've done is I've just created another entrance into my production API server. So this is not good. How can we stop this attack? Well, luckily, Cloudflare happens to have a market leading application security platform. So WAF, bot management, rarely missing, APIs protection. And we can look at implementing this in front of our worker. So firstly, how can we fix this one? Well, when we look at the application that agent Lee, I can close you, Lee, you've been useless. You've been no help whatsoever today. So let's close that. Lee would have deployed the application and we asked it to make it available on the Internet. And that's exactly what it did. But if you look here, it's deployed the application onto a workers.dev domain. Now, that's really good for quick prototyping, rapid iteration, trying out new ideas. But it's not really designed for production because workers.dev is not owned by you as an organization. You can't apply security policies to it as such. So let's turn that off. What that'll do is it will remove the application I deployed from that workers .dev domain. Now, I can connect it to something I do own. So I've got a Cloudflare account. I've configured all my security policy already. I've set up my bot management rules. I've set up my very limiting configuration. I want to bring my worker into that environment. So you can see down here, we've got custom domains and I've attached my worker into my custom domain. I'll show you a bit more of that in a minute. But while we're here in the workers pages, just as a general bit of good practice advice, when you are deploying workers, if I can, yep, down the bottom here. So Cloudflare access is Cloudflare's Zero Trust element of our SASE platform. One really good practice to do if your team are deploying workers into Cloudflare is just turn this on. And this will automatically protect any workers application you deploy with Cloudflare access. So it just removes that threat you just saw entirely. This works really well when workers are internal, they're private, they're not ever going to be on the Internet. In my case, I do want my application to be on the Internet. So I can't click this button over here. Previews only is a quite a cool feature where as your team are developing features that may be merging to new branches, adding features, then you can just generate a unique URL per worker feature. And you might want to protect that by access because that's still an internal feature being developed. So in my case, I want to leave the previews on, but leave all traffic still off because I want the Internet to access my application, just a bit with a bit more security in front of it. And then you can define how that policy works. So really good tip for deploying workers into your account. So where do we get to? I've now moved my worker into my account. What does that mean? Well, if I go into the domain that I added it to, which was in here, there we go. So I've got my security dashboard. I've got my bot management turned on. So I'm blocking requests that come through with a low bot score. I've got a rate limiter in there because I don't want, it's very unusual that a human would send more than, I don't know, five requests in a minute for a one-time pin. So you can enforce those kinds of rate limits. Very basic, trivial security tools, but very important that they are in place. And then finally, you've got the Cloudflare WAF turned on as well. Just on the note of the Cloudflare WAF, you may have heard about the PHP vulnerability. I think everyone's heard about the PHP vulnerability that dropped last night. One of the reasons you want to deploy applications into a secure environment is because we never know what the next vulnerability is going to be. And by deploying a worker into a secure environment, not saying that workers uses PHP, but in this case, you would have been protected straight away from that vulnerability. So another good reason to make sure that as your teams are deploying their vibe coding projects into an environment, they inherit security by default. So what I showed you there was deploying a worker, maybe in a less good practice way, it got attacked and we removed it and put it into a secure environment. But how can we make this the default rather than just fixing it after we've already had the attack? So there's two ways, two things I'd like to show you, or two patterns you can use to make this the default rather than having to run around fixing things. By the way, you can use Agently. If you've got a situation where you've got 100 workers deployed in your account, you're not sure where they live, you can use Agently. It will work for you, I promise. It was just me, I guess. But you can use Agently to actually ask it, which of my workers are not protected? Help me move my workers into a secure environment, and it will walk you through that process. But how do we make this the default? Well, you've got a couple of options. I'll open up an IDE, which may be more familiar in terms of a developer writing an application. This is the app in the middle. I've sent this agent exactly the same prompt as I sent to Agently. It's generated the project, and it's ready to be deployed. Now, you may have heard of Wrangler. Wrangler is Cloudflare's CLI for testing, prototyping, building applications on Cloudflare. It can also access the whole developer platform, so it can push secrets into SecretStore. It can access KV and viewable objects. But what we can do is we can use Wrangler to deploy the application rather than just doing it in the dashboard itself. Wrangler comes with a configuration file called Wrangler Toml or JSON, whichever version you're using. This is the Toml version here. Now, importantly, you can define a couple of very important settings in the Wrangler configuration file, and this just removes the workers.dev domain and the preview URLs just by default. So, when your development team are deploying workers, they won't ever land on a workers.dev domain. The second one down here is the pattern. So, I'm basically telling the worker to attach itself to my own zone where my security lives. So, I can run Wrangler deploy, and that's great. The problem with that is my agents can still access this configuration file, and these settings may not be enforced. So, we want a deployment pipeline to be looking at this ideally so we can enforce these values. The better way of doing this, in my opinion, is to use workers builds. Now, what I've done with this agent is I've asked it to make all the changes, create the application, and then open a PR against my repo so I can then go in and approve it, and an agent may well go and approve this. You'll see at the end of the prompt here, it's opened a PR. Open the PR, and then I can review that PR. This is the new application that's going to sit in front of my production API. I can just merge that PR. I go back into the Cloudflare dashboard, go to my workers page, and then you'll see down here, this is the application that is deployed using this good practice. It's called connect sign-in demo. It's been attached to my own domain, so chrisadam.dev, and you will see it might have already finished, but you will see that what I did there was I merged a PR in GitHub. I've connected my project in Cloudflare to that GitHub repository, and you'll see down here that there's a build running because Cloudflare has detected that I've merged a PR on main in the GitHub repository. That agent never touched Cloudflare. The agent never had access to Cloudflare. It never had a Cloudflare API token. All it had access to was the repo that it made the change to. I've then set up as a security person at Cloudflare, who owns this account, I've set up a synchronization between Cloudflare and the repo. When I've merged that code, it's then pulling the repo in, and the demo, because I'm really not on my side today because this usually takes five seconds to deploy. What will happen now is that will get pulled into Cloudflare, built and deployed as a worker within my secure environment, and be protected from those threats that we saw earlier. I'll let that finish. Just to summarize then, when you're deploying workers, we want to make sure that the application arrives inside our secure predefined security boundary. What we did at the beginning there was what this looks like here. It was an application deployed onto workers .dev. Great for prototyping, really quick and fast, but also good from a security perspective. What we want to do is this. Move the application we're deploying into the secure boundary, and make sure that it inherits the security you have in place for the rest of your production environment. Just to wrap up then, and have some time for questions, there's three ways that I've talked about right now anyway, of deploying apps with Cloudflare. Number one, lots of freedom, very fast, good for quick prototypes. The agent just writes code and pushes it up to Cloudflare. You don't have much control over that in this example. Number two there was using guardrails in the configuration. Again, really good for somebody that's a bit security-minded. They have access to the Wrangler configuration file. They are controlling where it lands in the configuration file itself. That gives them a lot of freedom without imposing too many guardrails. Then the last one is probably the most secure in terms of secure development. You have an agent that writes code. It opens a pull request on existing projects. That project is linked to Cloudflare through workers builds. Workers build will detect the merge into main, and it will then pull in those changes, rebuild, and redeploy the application on Cloudflare, but importantly, inside your secure boundary. You are not going to be exposed to SMS pumping attacks, and the big scary Internet that exists, and the rapidly changing landscape that we face ourselves with. Essentially, let AI write more, and more, and more, but make sure that we control where the application lands. In this case, in a Cloudflare secure environment. That's everything I wanted to share with you today. Thanks very much.