Вадим

А WSL2 вы устанавливали?

просто удаляете все файлы с диска, кроме /home
там находятся ваши конфиги "домашних" программ
и ставите убунту на диск без форматирования + доп. ПО.
то же имя пользователя
емнип ещё chmod -R olduser
и можно работать дальше.

Не соглашусь с коллегами что 'нечего там учиться, и так все понятно' :) Тема большая и интересная, там копать не перекопать.
Я не специалист, но картинка представляется такой:
- по информации - курить owasp, как минимум. Попадались сайты с переводами статей с оваспа, и своими материалами по web security;
- по разработке - обвешиваетесь статическими анализаторами (SonarQube, Bandit для питона, и тд). Анализатор укажет подозрительные места, а вы прокачиваетесь в понимании возможных векторов атаки;
- по тестированию - проверять сканерами типа OWASP Zap, https://www.ssllabs.com/ssltest/analyze.html . Опять таки, разбор срабатываний даст понимание того как вас могут атаковать, как можно делать, и как нельзя;

Безопасная веб разработка - это по сути CORS, CSP, защита от XSS, защита от CSRF и хеширование паролей

UPD:
Вадим, Если вы не хотите чтобы к вам на API прилетали данные, которые вы не ожидаете - используйте валидацию с whitelist'ингом. Если вам нужно ограничить места, откуда может прилететь запрос - сконфигурируйте CORS.

Если вы хотите ограничить количество запросов на эндпоинт в течении какого-то количества времени с одного IP - Юзайте RateLimit. Про правильное построение авторизации тоже не совсем понятно. Что для вас правильнее: JWT или OAuth2? Все стратегии уже давно придуманы и сделать что-то неправильно будет тоже сложно.

Нужно безопасно предавать данные в сети - HTTPS и SSL.

Хотите закрыть все порты, кроме 443? - юзайте фаервол.

Нет необходимости изучать «принципы безопасной веб разработки», вы когда что-то писать начнёте, вы сразу увидите все слабые места и начнёте искать пути решения уже конкретно под вашу ситуацию. А так, свой

fetch('https://api.com')

вы безопаснее не сделаете.

tcptraceroute domain.tld 25
это если нужно глянуть ноды через которые пакеты идут получателю на 25 порт

в заголовках письма есть только отправитель и получатель, причем у принимающей (отправляющей) стороны (домена) может быть каскад smtp серверов, через который пройдет письмо прежде, чем упадет в ящик получателя

Смотрите заголовки Received, как правило в них есть вся цепочка начиная от формирования письма. Можно воспользоваться чем-то типа https://toolbox.googleapps.com/apps/messageheader/ - но обычно все гораздо лучше и больше видно по самим заголовкам. Вот, например, заголовки Received письма полученного через списки рассылки:

Received: from smtp2.osuosl.org ([140.211.166.133]:43816)
	by mx242.i.mail.ru with esmtp (envelope-from <openid-specs-risc-bounces@lists.openid.net>)
	id 1nD7cH-000BCL-Nx; Thu, 27 Jan 2022 19:27:22 +0300
Received: from localhost (localhost [127.0.0.1])
	by smtp2.osuosl.org (Postfix) with ESMTP id 818F640207;
	Thu, 27 Jan 2022 16:27:16 +0000 (UTC)
Received: from smtp2.osuosl.org ([127.0.0.1])
	by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 0oLF9wJ5GV1X; Thu, 27 Jan 2022 16:27:15 +0000 (UTC)
Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34])
	by smtp2.osuosl.org (Postfix) with ESMTP id F27D4401DD;
	Thu, 27 Jan 2022 16:27:14 +0000 (UTC)
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by ash.osuosl.org (Postfix) with ESMTP id 4A7A21BF84C
 for <openid-specs-risc@lists.openid.net>; Thu, 27 Jan 2022 16:27:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 36EB3401DD
 for <openid-specs-risc@lists.openid.net>; Thu, 27 Jan 2022 16:27:11 +0000 (UTC)
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 6ALaTL5qxGLX for <openid-specs-risc@lists.openid.net>;
 Thu, 27 Jan 2022 16:27:09 +0000 (UTC)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77])
 by smtp2.osuosl.org (Postfix) with ESMTPS id B051F400CC
 for <Openid-specs-risc@lists.openid.net>; Thu, 27 Jan 2022 16:27:09 +0000 (UTC)
Received: from rcdn-core-7.cisco.com ([173.37.93.143])
 by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA;
 27 Jan 2022 16:19:37 +0000
Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19])
 by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 20RGJaJO009169
 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK)
 for <Openid-specs-risc@lists.openid.net>; Thu, 27 Jan 2022 16:19:36 GMT
Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xbe-rcd-004.cisco.com
 (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 27 Jan
 2022 10:19:36 -0600
Received: from xfe-aln-005.cisco.com (173.37.135.125) by xfe-rtp-001.cisco.com
 (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 27 Jan
 2022 11:19:36 -0500
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57)
 by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14
 via Frontend Transport; Thu, 27 Jan 2022 10:19:35 -0600
Received: from BL0PR11MB3267.namprd11.prod.outlook.com (2603:10b6:208:6b::22)
 by BL1PR11MB5318.namprd11.prod.outlook.com (2603:10b6:208:312::24)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.17; Thu, 27 Jan
 2022 16:19:35 +0000
Received: from BL0PR11MB3267.namprd11.prod.outlook.com
 ([fe80::c981:5c34:715b:b3a6]) by BL0PR11MB3267.namprd11.prod.outlook.com
 ([fe80::c981:5c34:715b:b3a6%3]) with mapi id 15.20.4930.018; Thu, 27 Jan 2022
 16:19:34 +0000

Для начала покажите код из конфига nginx относящийся к location который вы пробрасывали.

Дока на сайте nginx - https://www.nginx.com/blog/websocket-nginx/

защита работала из коробки, без доп. манипуляций.

универсальной защиты не бывает, а это значит, что или надо будет предпринимать какие-то меры на основе того, что происходит (когда настроенная защита не предотвращает ddos), или довериться профессионалам, тем же qrator и подобным, если вы возьмете их услуги. Или же смириться с достаточным уровнем защиты от сетевых атак, которые закроют условные 80% всех случаев DDOS

решение с которого можно начать, чтобы не думать, как мне кажется, это cloudflare
aws предоставляет достаточный уровень базовой защиты всех публичных эндпойнтов, но для более продвинутой защиты используются дополнительные сервисы, за дополнительные деньги, а еще их настраивать надо. самому.

ip_forward включили?

# cat /proc/sys/net/ipv4/ip_forward

iptables/nft forward цепочки смотрели?

Тут главная идея в том, чтобы получать как можно большое обратной связи от каждого stage
Вот, скажем, сломался у нас build - мы должны узнать об этом как можно раньше и со всеми подробностями: где, как и почему сломался.
Аналогично lint - где, как и почему у нас нарушается code guideline.
Аналогично test - какой тест и как именно рухнул.

Если build docker даст вам такую же точную диагностику где что и как сломалось - собственно почему бы и да? Но лично я бы разделил на отдельные шаги, по принципу unix way. Так проще всем этим управлять будет.

build не включает все - есть тесты разных видов (от unit до end-to-end), static code scanner, и т.п.
Так что CI/CD не исчерпывается docker build.

pip более стабилен и распространён, чем редкий и никому ненужный pipenv.

Медленно, иногда на порядки.