PII Data in Get Requests

[RestIsSexy]

Hi !

Is it still considered best practice to use POST to retrieve information to avoid exposing sensitive PII information in URL's ? Example below .

GET /accounts?phoneNumber=8665551212  // find account by number
GET /lines/8665551212/usages          // get usages for number

One alternative that comes to mind is to use a search endpoint

POST /accounts/search { phoneNumber=8665551212 }
POST /lines/search/usages { phoneNumber=8665551212 }

[James Higginbotham]

Hi,

Yes, this is still considered a common practice to use POST rather than a GET for PII/NPI fields when used as query args. The primary reasoning is that most infra and ops teams log HTTP requests to disk and/or log analysis tools like Splunk, thereby leaving this kind of information available for discovery. 

For values submitted as part of the path, you should use a different identifier for the get usages endpoint to avoid using sensitive details in URLs. e.g. GET /lines/<internal_identifier>/usages. That would prevent you from needing to use POST everywhere, but would require the code to perform the lookup by this alternate key. 

Some teams have opted to use a reference id, which may be encoded and optionally combined with the system of record with the internal identifier, making the ID opaque and your API resilient to M&A or other kinds of issues where multiple systems of record may exist over time. 

James

[miqui]

hi James... what about PII in a header? (perhaps some ops teams grab this data as well?)

rgds

[Derric Gilling]

Just to add to James comment, I would not recommend adding details on the query itself to the HTTP header. 

Headers are used for additional metadata about the request, but not recommended to contain the exact query. Helps to have some separation of concern there. 

This can also complicate any caching if the URL and body is the same but you don’t correctly set the Vary header.

Most API frameworks don’t have built in validation for headers (whether it’s a positive number, etc) creating unnecessary code. 

Thanks,

Derric

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/api-craft/29821d46-8ee9-4ceb-86db-6e11e554fff9n%40googlegroups.com.

[RestIsSexy]

Just to follow up on this discussion, we decided to tokenize all customer PII information , similar to credit card information.

Has anyone heard of other companies doing this ?

[Nirmalkumar Seshachalam]

Hi Sunil Srivastava,

May you elaborate the way you have leveraged the tokenization for PII data?

Regards,

Nirmal

Virus-free. www.avast.com

To view this discussion on the web visit https://groups.google.com/d/msgid/api-craft/abb630e1-ac37-45d7-bacf-e013c14f161fn%40googlegroups.com.

--

Nirmalkumar Seshachalam

email: nirmalkumar...@gmail.com
Phone: +91-9944123039 

http://fr.linkedin.com/in/nirmalsesh

Virus-free. www.avast.com

[RestIsSexy]

We've built a tokenization /de-tokenization service that takes a string and returns a token that is stored. E.g. when a customer input their address the service will call this tokenization service which returns a token that is stored by this address service.