Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Looking to build an analytics system? This post covers storing time-based metrics vs user-centric metrics.
In just a few short years, data-driven teams went from not enough data to drowning in a sea of metrics. Every action, reaction, and result can now be tracked, processed, and analyzed. However, a key question we’ve received is which metrics are important and which analytics architecture and data store is best suited for a particular analytics requirement.
APIs drive the digital economy. They are fundamental to today’s commerce. Rate limiting of APIs is used to ensure availability and prevent abuse.
While ensuring high availability, APIs need to meet SLAs defined for users. To meet these SLAs, checks are necessary so that one user does not overwhelm the system.
When we’re designing APIs, the goal is to give our users some amount of power over the service we provide. While HTTP verbs and resource URLs allow for some basic interaction, oftentimes, it’s necessary to provide additional functionality or else the system becomes too cumbersome to work with.
An example of this is pagination: we can’t send every article to a client in one response if we have millions in our database.
This week, we check out the API vulnerabilities in the WordPress Rank Math plugin, Tapplock smartlock, and TicTocTrack, another kids’ smartwatch.
In addition, an update to VS Code OpenAPI extension that adds static application security testing (SAST) for composite API contracts has been released.
This week, GitLab has fixed several vulnerabilities, including API vulnerabilities, and the draft for OAuth 2.1 has been released.
If you find yourself stuck at home with extra time in your hands, why not check out the free course on web security that Stanford University is offering?
We’re seeing more businesses utilize microservices, service meshes and APIs to break down large, static applications and merge legacy systems with modern IT platforms. These agile and flexible application structures have changed the way we exchange data and are typically the method of choice when sharing data with external parties.
Microservices architecture is ideal for developing and updating mobile applications because it can simplify data sharing. In fact, according to recent research from Advanced Market Analytics “mobility and app proliferation is the primary factor augmenting the demand for API management” and they also point out “API security issues” as a potential constraint to growth.
For the last few years, there has been an explosion of API-powered businesses. There are revenue-generating APIs, developer platforms, partner marketplaces, and even internal APIs powering single-page apps.
With this explosion, there has also been a large increase in API tooling to help these companies go to market with their API platforms as quickly as possible and out-innovate any competition. Much of this increase in tooling mirrors what we saw in the mobile era. However, with this explosion, there is now an increase in the number of tools and solutions to build and grow APIs and platforms.
Each developer relations program has a different opinion on what should be north star metrics to measure the success of their platform. Some metrics are valid while others can be what are called vanity metrics. This post discusses which metrics you should or should not be tracking.
The goal of developer relations is to ensure third-party developers are able to leverage your platform to create something of value. Value can be subjective, but some examples include shipping a new integration or plugin that increases the usability of your products or integrating your APIs and SDKs into their web or mobile apps to deliver a better experience for their customers.
Purchasing a new enterprise analytics solution can be a great experience if you’ve never purchased software before, yet it can be a daunting task. There can be a variety of analytics vendors with overlapping features for a use case yet each has its strengths and weaknesses. As an alternative to purchasing ready-made SaaS, you can also build your own in-house API analytics infrastructure on top of open-source software like Spark, Druid, and Elasticsearch. This article digs into when it makes sense to build vs buy ready-made analytics solution and provide a point-based framework for evaluating API analytics solutions and perform the proper diligence.
The first decision a company should make is whether they want to build the infrastructure or purchase a ready-made solution. There are benefits and risks to both. In general, purchasing shortens the delivery of a well-polished analytics solution with lower cost in time and money compared to homegrown, but a homegrown gives you greater control over what is tracked and presented.
This week, new security issues have been reported in a US election app, Voatz, and an API vendor has leaked 8 million shopping records in UK. In addition, ESG have shared some of their findings on API security and DevSecOps, and there is a new API security extension for Azure Pipelines.
We have already covered vulnerabilities found in a previous MIT security research on the US election app Voatz in our newsletter issue 72. Now, another security research on the app has also been published.
This week, the state of security in Zyxel’s management console as well as in the field of IoT leaves room for improvement.
Meanwhile, on the presentation front, we have an upcoming webinar on API DevSecOps in Azure Pipelines, and recordings from BSides SF 2020 are out.
You have an API program that developers are adopting, but unsure how much. How long does it take for a new integration to move to revenue generation? If you came from a web or mobile product management background, you may already be familiar with mobile product analytics to measure app engagement and retention. Growing APIs have similar KPIs to measure the success of your API program. This article will talk more what you should be measuring and how to leverage that information.
While traditional customer funnels will consist of just a marketing and sales funnel component. However, APIs as a product where customers and partners include developers have what is called the developer funnel or integration funnel. The developer funnel is after the marketing funnel and before the sales funnel and has three core stages:
There are few metrics more critical than retention for a platform business. If you’re acquiring customers for $25, but they stop using your API after a month, then you have a leaky boat. Don’t spend more money on developer acquisition until retention is fixed. This requires accurate measurement of API retention.
If you came from a web or mobile product background, you may already be familiar with mobile retention to measure how many acquired users keep using a mobile app. Growing a B2B platform requires tracking similar KPIs to measure the success of your acquisition and product strategies. This article will dig into the best practices for tracking and increasing API retention.
This week, we check how Tinder’s API vulnerability has developed a life of its own, the latest statistics from Akamai on API security, the best current practices for JWT, and why API security needs both API firewalls and API management, not just either-or.
Back in July 2019, we covered the OWASP API3:2019 — Excessive data exposure vulnerability in Tinder APIs. The premium features, such as unblurred images of those who like you, were not enforced on API-level. Thus, a suitable crafted request to the API could by-pass these restrictions.
This week, we take a look at how WordPress got exploited by a 3rd-party plugin and how API security research can sometimes be a very ungrateful endeavor. In addition, we also have the cost of ignoring API security as showcased by Facebook as well as several good JSON Web Token (JWT) talks. And as a cherry on top, we have a patch release to the OpenAPI Specification (OAS).
WordPress REST APIs got exposed and exploited through ThemeREX Addons plugin, installed on about 44,000 sites.
This week, we take a look at the recent API vulnerabilities found in SoundCloud and the electric scooter service Lime. In addition, we have a set of tips for API penetration testing, and NIST whitepaper on the microservices security.
Paulo Silva has published a very systematic and thorough report on API vulnerabilities that the Checkmarx Security Research team found in SoundCloud. (SoundCloud has promptly acknowledged and fixed the issues.)
You may also like: Analyzing API Call Performance From Different Global Locations Based on cURL Metrics
This week, we check out a recent API vulnerability in Twitter. In addition, it looks like API vulnerabilities are a bit of a theme in apps by political parties: vulnerabilities were discovered in apps by Israel’s Likud and the Democratic Party in the USA. We also have two API security talks: one recorded and one upcoming webinar.
Twitter has disclosed a recent API exploit. The API endpoints to make finding friends in Twitter by their phone numbers easier were abused, possibly by state-sponsored actors, to mine accounts by mapping them to phone numbers. Detecting and throttling the exploit was hard because the phone numbers were not sequential and attackers used multiple accounts and IP addresses in their attacks.