Hi, I interested to use Mongodb Atlas App Services for new projects
but i’m not found some elements to ban, block ip or use trigger on failed login to ban ip trying to brute force password/login for example.
Do some features exist to secure the app services ?
A lot of that is logic you need to build. Otherwise you have white listing and black listing.
Thanks you Brock, a lot a information with your answer.
So you confirm my first impressions 
I will read again the Mongo Docs to see what i can do on the Grapqhl / API app services authentification part.
Thank a lot Brock.
Not quite, the email/password functionality works fine, but the controls to block or ban failed login attempts is your job to implement and build within your app like any other services.
Just as logging failed login attempts and determining timeouts and so on.
Of course the service is ok but i need to ask first before considering some features as ready to use.
This one is not production ready because the features need some adjustments.
I says so because some mongodb youtube official videos suggest the “ready to go” but it’s just introduction and commercial promotional material. I needed some confirmation than i need to add it by myself.
If the features was already on the services, i wanted to be sure i was not missing it 
On that I can agree, there are a lot of company produced materials that are introductory. But that’s also where experience comes in to know the pieces you need to build on your own, and how things intercommunicate.
On the flip side, the fact as a corporation everything is introductory, you can make your projects and tutorials stand out even more.
Same reason my GraphQL tutorial has turned so far into a book for interfacing MongoDB and Atlas with GraphQL, etc.
But also you need to understand there’s a lot of features like GraphQL that are partially supported, but not fully supported. (custom scalars, enum scalars, passing payloads, etc) which does create its own challenges, but you can build around it. But it does test how much you actually know about GraphQL in that example.
@DomC as some things were brought to my attention from elsewhere, (Not MongoDB, barely ever talk to anyone from it these days) I just want to be clear I am not employed by MongoDB, nor sponsored by it. Separation from MongoDB was back in end of Nov due to fictitious drama from someone external to MBD that I won’t get into here.
But in large I am very objective when it comes to MongoDB or any company for that matter, I just want to make it clear I’m not white knighting, nor am I worried or afraid of producing criticism or opinions about products or services, or actual known public facts. (Much of the time I wait until someone else exposes a problem I found previously before talking about it.)
In relation to your GraphQL that I’d like to make clear, yes, there are a lot of functionalities that aren’t supported, despite Apollo GraphQL fully supporting it. Yes, I can see where you can feel it isn’t production ready, in some aspects I do agree with you and on other aspects I have to heavily disagree. Because you should not be focusing on just GraphQL to secure your environment, nor should you be making Atlas itself the core focus of securing your environment.
Security is a culture, not a product. You need to make sure that you firmly understand that, in which your database is only one layer of the onion whether the feature is organic to it or not, there is always other ways to implement what you need.
This is coming from someone who’s worked on NIPRNET and SIPRNET networks and applications, who’s also worked on and developed applications used I can’t even discuss or go into specifics of that are used in high security environments.
I’ve also worked on penetration testing tools, RATs, vulnerability assessment tools, even reverse engineering tools to identify and break down an application to its machine code functionalities from compilation for exploitation.
When I say this, I do mean it. You will never have a fully secured environment, and there will always be a security vulnerability that you need to make the conscious effort to either accept the liability or mitigate the threat.
You also need to make stronger efforts besides password/email auth to really evaluate whether an application or service does, or can meet your applications needs. Coming from someone who’s assessed many applications for various reasons, even when people were panicking Seagate Harddrives had spyware built into them, you’re talking to one of the men who evaluated whether or not the situation was hyperbole. I also know the security team from the Air Force that handled the Ukraine power plant hack, and later worked in the evaluation of vulnerabilities and root causes of what allowed it to be breached in the first place. That’s my name among several in the report to Congress in 2016, and the report given to the EU by the company I contracted with when I say this.
If you would like help in working out the needs requirements for your application, and mitigations that could potentially workout what services may help you out, just let me know as I don’t mind. But “Atlas with GraphQL makes Brute forcing easy.” isn’t entirely accurate as you’re focusing on a server authentication and login error count without a handler. Which if MongoDB did implement said kind of handler feature, you then need to work on, and ensure it’s in sync with your SSO/LDAP/ETC. systems. Have a way to handle or mitigate false positives, and so on. Which honestly, your SSO solution, not Atlas should be responsible for that, but that’s just MHO.
And I would have edited and added this to my other post, but for some reason the edit button disappeared early? I’m not exactly sure.
Just my $0.02
Yes, we are talking about the same thing actually.
EDIT: My bad, I got a web scraper that’s pulling my posts and posting for me, it didn’t indicate your IR was deleted.