{
    "version" : "https://jsonfeed.org/version/1",
    "content" : "news",
    "type" : "single",
    "title" : "The API Briefing: Practicing Safe App Development with Secure Federal APIs |Digital.gov",
    "description": "The API Briefing: Practicing Safe App Development with Secure Federal APIs",
    "home_page_url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/","feed_url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/2015/03/04/the-api-briefing-practicing-safe-app-development-with-secure-federal-apis/index.json","item" : [
    {"title" :"The API Briefing: Practicing Safe App Development with Secure Federal APIs","summary" : "When browsing the various APIs offered by the federal government, you may have noticed that developers need to sign up for an API key. You may have also noticed that the documentation tells app developers to access the API using specified methods. Along with these two requirements, federal API creators","date" : "2015-03-04T12:10:13-04:00","date_modified" : "2025-01-27T19:42:55-05:00","authors" : {"bbrantley" : "Bill Brantley"},"topics" : {
        
            "application-programming-interface" : "Application programming interface",
            "security" : "Security"
            },"branch" : "bc-archive-content-3",
      "filename" :"2015-03-04-the-api-briefing-practicing-safe-app-development-with-secure-federal-apis.md",
      
      "filepath" :"news/2015/03/2015-03-04-the-api-briefing-practicing-safe-app-development-with-secure-federal-apis.md",
      "filepathURL" :"https://github.com/GSA/digitalgov.gov/blob/bc-archive-content-3/content/news/2015/03/2015-03-04-the-api-briefing-practicing-safe-app-development-with-secure-federal-apis.md",
      "editpathURL" :"https://github.com/GSA/digitalgov.gov/edit/bc-archive-content-3/content/news/2015/03/2015-03-04-the-api-briefing-practicing-safe-app-development-with-secure-federal-apis.md","slug" : "the-api-briefing-practicing-safe-app-development-with-secure-federal-apis","url" : "/preview/gsa/digitalgov.gov/bc-archive-content-3/2015/03/04/the-api-briefing-practicing-safe-app-development-with-secure-federal-apis/","content" :"\u003cdiv class=\"image\"\u003e\n  \u003cimg\n    src=\"https://s3.amazonaws.com/digitalgov/_legacy-img/2015/03/FDAgov-API-Key.jpg\"\n    alt=\"FDAgov-API-Key\"/\u003e\u003c/div\u003e\n\n\n\u003cp\u003eWhen browsing the various APIs offered by the federal government, you may have noticed that developers need to \u003ca href=\"https://open.fda.gov/api/reference/#authentication\"\u003esign up for an API key\u003c/a\u003e. You may have also noticed that the documentation tells app developers to access the API using specified methods. Along with these two requirements, federal API creators have several ways to provide secure APIs for app developers and the general public. In this posting, I will describe how federal APIs are kept secure.\u003c/p\u003e\n\u003cp\u003eTo understand API security, you must first understand what a “session” is. When a user (through a browser or an app) connects to an API and information is exchanged, this is known as a session. A session lasts as long as the connection lasts. An analogy I like to use is going through a drive-thru. When a customer drives up to the menu board and orders, the customer has initiated a session. The clerk takes the order and then prepares the food. The food is delivered to the customer who then pays for food. The drive-thru session is over when the customer has driven off.\u003c/p\u003e\n\u003cp\u003eSessions are either “stateful” or “stateless.” If one of the parties to a session needs to keep track of the session information, then the session is stateful. In the drive-thru example, the clerk needs to keep the order information so that he or she can tell the kitchen what to cook and how much to charge the customer. This is why the drive-thru session is stateful. If no information is being kept between requests during a session, then the session is stateless. Buying food and drink from a vending machine is stateless.\u003c/p\u003e\n\u003cdiv class=\"image\"\u003e\n  \u003cimg\n    src=\"https://s3.amazonaws.com/digitalgov/_legacy-img/2015/03/FDAgov-API-authentication.jpg\"\n    alt=\"FDAgov-API-authentication\"/\u003e\u003c/div\u003e\n\n\n\u003cp\u003eAuthenticating who is interacting with an API during a session is important to the security of the API. One way to be secure is to use a username and password combination, but many API providers prefer to use API keys. API keys can be longer than passwords and much more random so that it is very difficult for a third party to spoof an API key. API keys also make it easier to keep the API session stateless. A stateful API session that uses the username and password combination would have to store the username and password making it riskier that the security information would be discovered.\u003c/p\u003e\n\u003cp\u003eAnother security practice is to use the appropriate REpresentational State Transfer (REST) verb. For example, an API provider can require the developer only to use “POST” which does not display information on the Uniform Request Locator (URL) request like “GET” does. For example, if the developer uses GET to send the API key information, it would look like this: \u003ca href=\"http://federalapi.gov/action?apikey=a53f435643de32\"\u003ehttp://federalapi.gov/action?apikey=a53f435643de32\u003c/a\u003e. Now, anyone can use the same API key. It would be like if the developer used GET to transmit a credit card number and expiration date.\u003c/p\u003e\n\u003cp\u003eA fundamental security practice is to limit the kind of methods that an API provides. For example, an API can be read only whereby the developer can only view information but cannot change the information in the API’s data in any way. For example, the \u003ca href=\"http://search.ams.usda.gov/farmersmarkets/v1/svcdesc.html\" target=\"_blank\"\u003eU.S. Department of Agriculture’s Farmers Market API\u003c/a\u003e allows developers to request data on farmers markets but developers can put in new data or change any of the entries. If an API allows “write” access, the API creator can still limit what information will be written to the API and require approval before the data is altered.\u003c/p\u003e\n\u003cp\u003eThere are more methods to secure APIs. As APIs become more used and vital to applications, developers need to verify that API information is accurate. Using federal APIs helps build trust in apps because federal API creators take great care in building incredibly useful and highly secure APIs.\u003cem\u003e*API – Application Programming Interface. How software programs and databases share data and functions with each other. Check out \u003ca href=\"/preview/gsa/digitalgov.gov/bc-archive-content-3/2013/04/30/apis-in-government/\" target=\"_blank\"\u003eAPIs in Government\u003c/a\u003e for more information.\u003c/em\u003e\n\u003cem\u003eEach week in “The API Briefing,” I will showcase government APIs and the latest API news and trends. Visit this blog every week to learn how government APIs are transforming government and improving government services for the American people. If you have ideas for a topic or have questions about APIs, please contact me via \u003ca href=\"mailto:%20bill.brantley@wdc.usda.gov\" target=\"_blank\"\u003eemail\u003c/a\u003e.\u003c/em\u003e\n\u003cem\u003eDr. William A. Brantley is the HRIS Branch Chief in the USDA’s Rural Development Human Resources Office. You can find out more about his non-federal work in this space at \u003ca href=\"http://billbrantley.com/\" target=\"_blank\"\u003eBillBrantley.com\u003c/a\u003e. All opinions are his own and do not reflect the opinions of the USDA and GSA.\u003c/em\u003e\u003c/p\u003e\n"}
  ]
}