Bas Dijkstra on LinkedIn: Two talks on the same day at two different events: ✅ Yesterday afternoon,… (2024)

To me, one of the most interesting of the vulnerabilities in the OWASP API security top 10 is Unrestricted Access to Sensitive Business Flows, or UASBF.If your API exposes access to business processes (room reservations, ticket sales, … ), having a good authentication mechanism and role-based access control in place isn’t enough to declare your API secure.At some point, preferably as early as possible, someone needs to ask the question of‘Can we find a way that people can abuse this business logic through our API?’Is there a way someone can leverage our API to scalp all the tickets? Can someone with malicious intent flood our system with fake reservations?API security is more than just ‘technical’ security (authorization, permissions on resources, etc.). You also need someone asking the right questions from a business perspective.More about UASBF in an upcoming (and bloody long overdue) blog post after the weekend.

21

Really looking forward to the EuroSTAR Conference in Stockholm next week, and most of all to meeting so many testers from all over the world and talk about testing, automation, development, and probably lots of other things, too.It is my first ever EuroSTAR, somehow going there never really materialized before, but this time, as a member of the program committee, I couldn't not go.If you're at the conference on Tuesday or Wednesday next week, come and say hi!

21

7 Comments

I’m still fascinated (and admittedly sometimes a little worried) by the amount of people and teams starting their test automation journey with learning to write full stack / DOM-to-DB tests.I mean, I get it. You’re used to working with the application you’re testing through the GUI, because it’s an interface (the only interface) written for human beings to consume.And you want to augment some of that testing with cleverly written scripts that help you confirm that things still work as you expect.But this type of automation is, by a significant margin, the most difficult type of automation there is. It’s the slowest to run and takes the largest amount of code to write.You’re dealing with the full Monty in terms of moving parts in your application. Every single one of those moving parts can potentially affect your test results. You’ll need to dig through all those parts when a test fails and you’re looking for the root cause.This is why I recommend everyone starting out on their automation journey to open up the hood of the application they’re working with. What other interfaces are there? What useful information do they expose? How can you write automation that retrieves that information in an efficient and reliable manner?I’m not saying you shouldn’t learn to write DOM-to-DB tests. They exist for a reason, and you’ll likely need a few of them as part of your test suite. At some point.But before you go all in on them, I recommend to first learn a little more about writing automation against interfaces that are written to be consumed by code, and that are therefore inherently easier to work with in test code. APIs. Databases. Your application source code.It will help you working towards a more efficient, reliable and valuable automation experience.

75

36 Comments

I'm doing another public workshop!After the success of my very first public workshop on API security testing earlier this week, I have decided to run a second workshop on September 9, for those who missed out the first time.So, if you're interested in learning more about API security and how to test for it using common API testing tools and a healthy dose of curiosity and creativity, tickets are on sale now! Link to the sales page in the first comment.EDIT: I'm thinking about running similar workshops on other topics related to API testing and test automation in general in the future, too. If there's a particular topic you would be interested in, let me know in the comments!

40

3 Comments

I'm declaring my first ever public workshop a success.Until now, I've never really ran public workshops or training courses, because they are a lot of work. Not the teaching / facilitating itself, but all the logistics and marketing it takes to get enough people to sign up. As an experiment, though, I thought I'd give it a go anyway, and it turns out I really enjoyed it. Did I sell all the tickets? No. Out of the 10 spots, I sold 5 (well, 6, but one person had to cancel, and I refunded their ticket).And that's great. It means I got to spend 4 hours with 5 great testers from around the world, talking about API security testing (the topic of the workshop), going through exercises, discussing ways to test for API security vulnerabilities and risk mitigation strategies.Thanks once again to the attendees, you made my afternoon.Am I going to do this again? Yes. Expect a new public workshop to be announced soon. Pricing will be the same: EUR 229 for a 4 hour workshop.What topic would you like to see covered in my next public workshop?

19

9 Comments

Contrary to what some content I see here on LinkedIn suggests, a solid approach to testing (with) APIs encompasses much more than just learning about HTTP verbs and response status codes.Sure, these are important parts of an API (or rather of HTTP), but they’re only a start.If you want to properly learn API testing, here are some subjects I think you should focus on:* Exploratory API testing - to find out about potential problems with your API, especially in the areas that aren’t documented* API test automation - to confirm that an API conforms to expected behaviour that you codified in your tests on a regular basis (e.g. on every commit)* API security testing - with APIs being responsible for around 85% of Internet traffic these days, they’re an important attack vector to people looking for access to your data* API mocking - in certain situations, simulating (3rd party) systems at the API level can help you test earlier, more and more oftenAnd then there’s contract testing, which is a bit of a different beast altogether, but definitely also a topic worth learning more about.

43

5 Comments

The last couple of weeks have once again shown me the power ofa) having a good network,b) doing good work, andc) sharing without expecting something in returnI’m still not sure how this serendipity thing works, but it does, and I’m pretty sure the opportunities that have come my way are a result of the above.Rest assured I’ll keep working on these things.

67

5 Comments

Are you stuck in your test automation efforts and looking for a fresh take on your problem?Are you looking for an independent second opinion on your automation approach?Need some advice on how to become a better test automation engineer?I've made it much easier for you to book time with me. Simply go to https://lnkd.in/eMKz9ZiN and schedule a session using Calendly.Looking forward to talking to you soon!

5

We would have a lot fewer pointless discussions if we’d recognize most things are a spectrum rather than a binary choice.‘Automation or manual testing’ - no, you need both‘Developer or tester’ - no, most developers do test, most testers do at least some form of development‘Automation in code or ‘codeless’ automation’ - how about you recognize that different abstractions layers exist and that different contexts require different choices?Everyone, every team and every context is somewhere on that spectrum. Some are where they need to be (yay!), others would benefit from moving a bit closer to either end.Very few things, though, are either / or.And what works in your context might not work as well somewhere else.

137

17 Comments