Dmitry Bay

Попробуем отделить коней от людей, насколько это получится.
Говоря просто: API - для отдачи непосредственного среза данных, обычно в виде JSON, WEB - для отдачи целых страниц в виде HTML.

Всегда думал что api.php нужно для запроса от сторонних приложений, сайтов к твоему сайту для получения какой то информации, которую я хочу предоставить, без авторизации.

Ну, неправильно думали, ничего страшного. Точнее, очень узко. Вот есть у вас сайт, а потом вы решили сделать к нему в пару мобильное приложение. Оно стороннее? Ничего сделать с отданным через WEB HTML оно не сможет*, потребуется API.
Наличие или отсутствие авторизации тут совершенно ни при чём.

в тоже время используя api.php любой человек может запросить любой роут и получить кучу информации

Любой человек получит то, что вы ему отдадите. Никакого запрета (или сложностей) на внедрение авторизации в API нет.

Количество Middleware на web.php значительно больше, т.е. любой запрос проходит больше проверок перед тем как выдать результат.

Middleware - это любые обработчики, а не только проверки. Т.е. "больше обработчиков не значит больше проверок". Любые обработчики вы можете навесить и на API**. И их даже не надо писать отдельно, в Laravel уже всё есть.

В итоге вопрос, с точки зрения безопасности, производительности есть преимущества api.php перед web.php

С точки зрения безопасности разницы нет. API может быть несколько производительнее за счёт того, что обрабатывает и отдаёт меньше "лишнего". Но по этим аспектам их вообще не надо сравнивать, это всё равно, что выбирать между экскаватором и самосвалом по степени лёгкости угона того или другого.

* без костылей
** с поправкой на отсутствие сессии обычно

Видео в любом случае должно быть кем то сконвертировано, перед отправкой клиенту, варианты:
- Либо множество заранее подготовленных видео роликов с нужным качеством (ютуб так делает), потребуется сильно больше места на диске, но нагрузка на процессор будет сильно меньше + можно выбрать ночное время для обработки.
- Либо сервер, который будет конвертировать видео в реальном времени, но нагрузка на процессор будет сильно больше.

сугубо по коду -
1) вынести предикаты в отдельные функции для улучшения читаемости.
2) вообще код разбить на функции. Если только начинаешь учиться - перенеси все это в классы. Создай класс игрока, поля и тд. Заодно ознакомишься с SOLID (уточнения по мелочам и правда лучше к чату гпт)
3) если правда учишься и САМ написал код - переведи его в typescript. Это стандарт индустрии, мастхев.
4) if (confirm("Хотите сыграть еще раз?"))
вынести в отдельные переменные. Учиться не оставлять в коде прописаных от руки строк.

Основа основ - переписать это на мелкие ф-кции с нормальными названиями и четким назначением, чтобы код стал приятно читаем.

пока у меня все )

1. password_hash — это bcrypt формат. Если есть доступ к базе, то делаете нового юзера с паролем, забираете его хеш и просто перетираете им password_hash в базе у нужного юзера.
2. auth_key — это не релевантно.
3. confirmation_token — это не релевантно.

4.8.1. превышения Пользователем установленных для соответствующего типа использования ограничений и/или лимитов, а также в случае изменения Пользователем типа файла с целью обхода правил или лимитов, предусмотренных в Программе. Яндекс вправе предупредить Пользователя о предстоящих блокировке и удалении файлов. В случае неполучения ответа и/или корректировки лимитов, Яндекс вправе по истечении 45 (сорок пять) дней с момента первого уведомления, заблокировать Пользователя, а по истечении 180 (сто восемьдесят) дней с момента блокировки безвозвратно удалить его файлы и данные с дискового пространства.

5.2. Используя возможности Программы, указанные в п. 5.1. Лицензионного соглашения, Пользователь обязан действовать добросовестно и воздержаться от злоупотребления данными функциями. Пользователь в том числе обязуется воздержаться от организации массового файлообмена с использованием функций Программы. Яндекс имеет право применять правила, лимиты и ограничения, направленные на предотвращение, ограничение и пресечение массового файлообмена по правилам п. 4.5. настоящего Лицензионного соглашения.

https://yandex.ru/support/yandex-360/customers/dis...

на бесплатных тарифах страница шаринга используется для размещения рекламы.

В общем глупая идея у заказчика. Проше взять вторую впску послабже но с большим винтом HDD, который дешевле чем ssd

Возможно ли воплотить в жизнь это требование ТЗ

Чтобы "хранить" - без проблем. А вот чтобы "показывать на сайте с я.диска"... лучше забыть про эту идею. Разве что на сайте будет 2-3 человека.

PS. Про гуглодиск для "корпоративный сайт" вообще говорить не стоит если речь про юрлицо в РФ. Но с ним почти тоже самое.

Не знаю, насчёт учебников, но как справочник предпочитаю использовать этот сайт.
Обучаться по нему "по порядку" не пробовал. Так-то вроде всё давно знаю, но... делаешь перерыв в 2-3 месяца и уже забываешь, то что знал. Соответственно, лезешь, читаешь и вспоминаешь заново.

Нужен ли javascript для WEB пентестера?

Нужен, для поиска уязвимостей, анализа клиентской логики, обхода ограничений (например, формы), изучения скрытой информации в коде и манипуляций с dom. Это помогает выявлять xss, инъекции и другие проблемы безопасности.

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

Базовый набор:
- html/css для понимания структуры и стилей веб-приложений.
- http/https, куки, заголовки, cors, rest и сокеты.
- Основы OWASP Top 10 (XSS, CSRF, IDOR и др.).
- Браузерные DevTools, Burp Suite, ZAP, Postman.
- Базово популярные библиотеки и фреймворки (react, vue, angular).
- Методы минификации и обфускации js кода, а так же способы его анализа.

для WEB пентестера

Очевидно, что да

когда тебе говорят выполнить ТЗ, которое не является для тебя вызовом и занимает всего час времени, а потом не отвечают вообще - это довольно грустно

Это действительно грустно, позор этим компаниям. Но боюсь, что сделать с этим вряд ли что-то можно. Разве что пытаться вежливо, но настойчиво переспрашивать фидбек.

Стоит ли пытаться "удивить" проверяющего? Есть ли прок от того, что в задании, где просят написать коротенький код, я его дополняю, подключая celery, меняя базу данных с локальной на более релевантную, засовывая приложение в докер образ?

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

Стоит все эти техзадания публиковать и добавить ссылку на github в резюме, если она ещё не там.