Developer forum

Hi Kevin

Good question – you’re right to challenge IP-based restrictions in this context.

For APIs that are consumed directly from the browser (headless implementations), IP allowlisting is not a strong security mechanism on its own. In those scenarios the API is effectively public, and the primary goal is to prevent abuse rather than to make the API “secret”.

The public API is public by nature - and we think of it like this:

• Treating read-only, non-sensitive endpoints as public and protecting them with rate limiting, caching, and bot/WAF controls.

  • Rate limiting has been added: https://doc.dynamicweb.dev/manual/dynamicweb10/settings/system/webhttp/rate-limiter.html

• Requiring proper authentication (JWT) for anything user-specific or sensitive – which is already the case for user-related endpoints.

• Using IP restrictions mainly for being able to stop specific IPs in operations when they need to act fast (this is where it stems from) - and in server-to-server use cases (partners, backoffice, integrations), not for browser traffic.

IP filtering is useful in some scenarios, but it’s not intended as the main security model for public website usage. More robust access patterns (JWT tokens) are used for that.

We can add an option to add a bearer token like we do on the management api - but that key would be public if you create a headless implementation either way and can be seen in the browser devtools.... Or how would you use a bearer token to keep the API non-public?

BR Nicolai

In such API's the only guard would be some sort of short-lived tokens that only can be aquired from the server.

It could be even stronger if those aquired tokens are for specific endpoints, so that you can't access it all with any token.

I don't know if you've seen my demo (screen recording) of my prototyping of a security AddIn for DW10? If not I can send it to you.

Hi Kevin

I have seen the video. I would like though to follow an api 'best practice' or industry standard approach if we should do something. I would like to not go with a homebrewed solution.

One method could be to require JWTs for all endpoints - then it would be relatively simple to create an "anonyous user" in the backend of Dynamicweb that can be used to issue a browser session JWT distinct for each visitor - and send that in all requests. If a real user logs in, it is just to replace the JWT in requests with the signed in user JWT to support correct permissions and pricing. The JWTs can be issued server-side, they can be very short lived and they are unique for each visitor.

Permissions can then be used to setup limited access to endpoint (or collection of endpoints).

If you follow api "best practice" or industry standard approach I'm all for it because the "all is public" approach isn't very best practice or industry standard.

If permission mangement could be part of setting up endpoint access that would be awesome.

I have added that as a work item under https://doc.dynamicweb.dev/documentation/fundamentals/dw10release/releasenotes/workiteminfo.html?workitemid=27182

If you have a reference link to some docs or anything we can use as inspiration, that would be awesome. 

Thanks, Nicolai

Systems that expose public information are more strict in their data model.

For example: Contentful, Sanity, Umbraco Heartcore have a public Delivery API where anonymous users can access all published content and Sanity has a global ApiKey for that. In these system the content model for publishing content is where the security is possible to manage.

In DW10, we have some very strong endpoints with very little control like

• /dwapi/query (can reach any repo index and any data model - has nothing to do with published content)
• /dwapi/ecommerce/products/search (can reach any repo index that can serialize to a product model - has nothing to do with published products)

This is where the other systems have a completely different architecture in their Delivery API, and where Dynamicweb needs something else.

The endpoints for pages are restricted to no access to unpublished pages and the Content Index Builder doesn't index unpublished pages.
But products and groups are an issue - they lack the same control.