 Hello and welcome back. My name is Alan. I am the session chair for this session and the next I would like to now introduce Roberto Poli, who is an API expert at the digital transformation department Is there anything you'd like to say to people before you begin your talk? Oh, yes. Thank you to everybody and thank you to the great Europe Python community Cool. That's just it. I am Roberto Poli from the Italian Digital Transformation Department. I work to create an API ecosystem capable to connect the public and the private sector in Italy and to Provide cross-border services with other European countries. So I think we can start So today we'll share some of the security work we've done on our API guidelines and an open source tool to validate open API design There are many API security tools for runtime such as dynamic application security testing tools and Z attack proxy But the stock focuses instead on the design part are adding some tips We included in our API guidelines at the end we will present our open source tool to review API specification So one of the goal we had that we have in Italy is to uniform the API produced by The many Italian public agencies. This is challenging agencies are thousands and We are and even because we are transitioning from the old SOAP framework to a new one Which allows using rest and more generally HTTP APIs The solution involves creating API guidelines and validation tools So these guidelines and tools want to achieve reliable secure and Consistently designed services But this activity has its risk such as writing over like a complex bureaucratic specifications or Cronfall solutions in a closet and time-constrained environment To mitigate those risks we enforce formal API definition based on standards Description languages such as open API free and whistle and Our big lines are written engaging with the internet engineering task force communities So let's start with some security basics in the following slides We will focus on some grass to be our security ends The scrubbing API with formal language like open API free We can simplify many design checks. Remember. We have thousands of agencies that implement API We cannot check every single Agency so we need to provide tools so that every agency can do their work here. We can see several URL without HTTPS. It's very simple and below An unsecured API endpoint so all the checks are Made with a tool Open API allows for perfect checks such as Identify in appropriate media types for specific medias for example patch If you're curious on that you can just have a look at LFC 7386 the point here is that given a specification we can identify Non-compliant behavior automatically and Another OS API security top 10 is ensuring that APIs are probably rate limited so that the infrastructure can manage high throughput and block When there are too many requests adopting the red limit header draft just like the one we are working on inside the ATF Will ease the enforcement of this kind of policies well Let's speak now about HTTP header security. It's not just adding or removing specific headers like the one released here because for example, it is very important to Document how you intend to use caching. This is just an example here. We can create an automatic check or To specify the rules you want to enforce When you secure and use authorization Bureau tokens Then in the specification you should explain why how you intend to use This kind of Bureau tokens Another important thing always overlooked is that since HTTP headers convey security and integrity information Ensuring that they are passed securely. It is important structure fields RFC 8941 Standardize a syntax to convey basic data structures for header processing and avoids using more complex and vulnerable formats like jazm and XML The snippet here shows how a pattern dictionary with various data types Integral strings bytes is used to initialize a dictionary object and is then serialized Automatically into an HTTP header so using the Python library for structure headers you can give another structure create automatically and header string value and On the other side the client just have to instantiate an empty dictionary object an empty structure fields header Dictionary object and then populate it with the data parsed from the HTTP response We can now directly access to the parsed data without creating a Header parser class or function essentially the nice thing is that if the data structure is Not conformant to the one we expect we have an parsing error that we can manage in the implementation for example Being tolerant if we need or in the general case to refuse Processing the header Okay, this was about header fields now. Let's speak about payload or content of HTTP message This is usually JSON or XML In API ecosystem clients and servers tend to use different frameworks So it is very important and parses So it is very important to limit the expressivity of complex languages just like JSON schema of XML schema to an interoperable subset in the case we see in the slides We cannot just rely on static validators, but we need proper dynamic testing with tools just like Scamophases or hypothesis the slides show some hints mostly taken from RFC 74 and 3 for example always use UTF-8 when using JSON and Code floats or begin to bear a string. Otherwise, we don't know what and how the language can transform the data avoid duplicating Names in keys in JSON. Otherwise the parser can just take the first or the second one We don't know which is the parser used by the client and then always use the strict parsing otherwise We can get rent root access to malintentionate users For XML, I saw a very nice talk today, but just have a look at OASP XML security cheat sheet and then complex stuff is about JSON schema It is important to constrain schemes because this simplifies validation and Clarifies the contract between client and server Here on the left. We can see how to constrain numbers minimum maximum Strings and even arrays remember there is no such a thing as an unlimited array So you have to constrain that More complex stuff depends with objects We should be very careful with just a schema object since the validator is very tolerant by default for example Properties are not required. We see the first example even an empty object or an object with a completely new property is valid. So we should require Specific objects, otherwise everything will just validate Moreover, additional properties are always accepted. So if we have a rigid schema with a required Property and some optional properties. We should remember to state that additional properties are not admitted While constraining fields is tricky because it might limit the evolution of your API But you should find your way You can increase constraints progressively together with use cases with both static and then tools to review schemas Okay Jots and Outsu As we showed before JSON and XML flexibility increases their attack surface So this is critical when using them to specify security assertions or to authorize claims other or authorization claims 12 implementers the Internet engineering task force or our work group Publish it at Jot best current practices including verify Algorithms avoid some specific attacks like substitution attacks use and validate some claims for example the sender the receiver designer of an Yes Identification Jot and don't trust received claims Moreover, it is important to follow those in for example limit Temporality of tokens add unique identifiers to tokens so that the receiver can implement policies to mitigate with their attacks and to not use private keys associated to TLS certificates to sign jokes because Doing that will expose you to cross protocol attacks You can have a look at the slides and click on the links the slides are available on the Europe I do a Europe item website There are even all two hints. For example, there are some authorization flow that are Considered my insecure such as the implicit and research owner password grant types There are other Specification that can be used instead There is a Jot bureau grant type they find in RFC 75 in 23 and Away to constrain the creation of access token to specific resources. This is specified in RFC 8707 Well, it's a lot of standards, but they are very short very simple. You can just have a look at that If you use those specification, probably you have already getting touch with that Well, this might seem a lot and It's just the tip of the iceberg of API security But the good news is that we are working on an open source API checker to guide implementers design secure APIs Open API checker is based on the open source spectral library. Thanks spectral team you can see the link to the spectral framework in the slides and The open API checker helps in reviewing the security The usage of standards and the usability of API So remember our goals in Italy is to uniform the design and security of the APIs Produced by 20,000 Agencies So here we can see a screenshot of the single page application of the open API checker. You can see there is an Issue red one is an HTTPS URL Then you can see various warnings such as an unsecured endpoint An unspecified cache policy an undefined schema and a Jot description That does not mention RFC 8725 remember RFC 8725 is just Jot JWT best current practices Well, of course All the screenshots you see before are taken from our Visual Studio Code integration with spectrum So you don't have to install almost anything just install the spectral Visual Studio Code integration and Configure the And unload our rule set or directly use the open API Online validator The Well, our goal is to foster this project involve more communities API expert and even People from other countries in our efforts that there are some other countries Which are using this tool to validate and simplify the API checks you can start trying the software online and get up And if you like you can even customize the rule set adapting them to our organization Well, it was a nice ride. I tried to be quick and fast all the information are in the slide presentation that is that are available. I'm Happy to Answer to your question Thank you. All right, thank you very much for the talk If anybody has any questions, please put them in the chat to begin with I would like to ask Would a lot of the work you've described sounds like it's working it with both the public and the private sector So I'm curious like what kinds of challenges do you have to deal with in terms of standardization and regular and regular Regulatory capture I guess as a result Well, it's very complex. It's a very complex matter But I think I wish I would I just want to share Perspective a vision I think that use case in in the public and in the private sector are not always different But the problem is that many times in the public sector Agentses tend to create double standards So they tend to replicate things that already exists in new standards instead of engaging early with With the ITF for example and share some needs So the real challenge now, yes It's regulatory because for example when we have sanitary data healthcare data We have a lot of regulatory stuff to check Agencies has to provide guarantees for both the public and the private sector for example when an agency Identifies somebody they guarantee your identity and that is legally binding and that impacts both the public and the private The point is that we have to be sure that Internet standards support public sector use cases instead Creating a new Application valid only in in the public sector because for example when the banking world had to Provide checks that are similar to the public sector. They had to rewrite Standards again, and that was the private sector. Okay, that makes that makes quite a lot of sense Because as technologists we've worked quite a lot with different forms of standards for API So as subject matter experts, we can sort of give governmental entities our expertise Whereas they may not have their own in-house teams and these sorts of things Think we have time for one more question Robert Price asks or Priya, sorry Which library would you recommend to use as a first start to to create secure API's? Oh? Wow, this is this is a nice catch I think that There is not not such a secure library For example when dealing with secure stuff. I quite like the Google think library with respect to the implementation of security features The point is that in security in the security world Everything changed very rapidly So the answer that is valid today May not be good tomorrow So I think that the nice thing the important thing is to start with a secure design oriented approach for example a correct specification of the data types and schemas probably constrain all that part means that you can have Not only libraries, but even frameworks or reverse proxies that validates the Schemas before that The request hits your server so Even of load in part the The work from the actual application server or the actual application framework that is that can but be fast API it can be Seneca it can be connection. I quite like connection Because it is very focused on Schemas and makes a lot of validation stuff But again on security. It's not just about the library I'm not stating that connection is a very secure library, but only that it helps you Comes in and even everything that comes out with that design first approach, but again A logical system you have you can have libraries that are different from clients and servers so Start with the design and then test Yep, that makes a lot of sense Happy to answer in the follow-up in the in the chart or in Yeah We will move into the brief break before the next speaker But I would like to remind everybody who is watching now that beyond the conference rooms and element We also have the breakout rooms. So if anybody would like to follow up with additional questions for Roberto Hopefully he can make some time to do so