REST и JSON — бесплатный тест онлайн

Вопрос 1 из 30

GET-ответ JSON автоматически превращается в объекты. Как исправить причину, а не только симптом?

$data=Invoke-RestMethod -Uri https://api.example.test/items -Method Get -TimeoutSec 20
$data | Select-Object -First 1

Успешный ответ без тела не обязан давать объект; код должен опираться на статус и контракт, а не вызывать свойства у $null. Параметры запроса нужно URL-кодировать через UriBuilder/HttpUtility или API клиента; обычная интерполяция ломается на &, +, пробелах и Unicode. Нужно ограничивать размер ответа, глубину модели и время запроса до разбора; корректный JSON способен исчерпать память. Объект следует сериализовать ConvertTo-Json с достаточной глубиной и передать корректный ContentType; передача самого объекта как Body может стать form-urlencoded. Invoke-RestMethod разбирает JSON и возвращает PowerShell-объекты; статус, заголовки и тело ошибки нужно при необходимости получать через переменные ответа или Invoke-WebRequest.

Вопрос 2 из 30

Тело POST строится из PSCustomObject. Где заканчивается гарантия этого механизма?

$body=[pscustomobject]@{name="alpha";tags=@("a","b")} | ConvertTo-Json -Depth 4
Invoke-RestMethod $uri -Method Post -ContentType "application/json" -Body $body

Заголовок строится как "Bearer <token>", но сам токен нельзя выводить в verbose, transcript или объект ошибки. Объект следует сериализовать ConvertTo-Json с достаточной глубиной и передать корректный ContentType; передача самого объекта как Body может стать form-urlencoded. Параметры запроса нужно URL-кодировать через UriBuilder/HttpUtility или API клиента; обычная интерполяция ломается на &, +, пробелах и Unicode. Invoke-RestMethod разбирает JSON и возвращает PowerShell-объекты; статус, заголовки и тело ошибки нужно при необходимости получать через переменные ответа или Invoke-WebRequest. Клиент должен ограничивать число страниц, проверять повторяющийся токен и агрегировать результаты потоково, чтобы ошибочный API не создал бесконечный цикл.

Вопрос 3 из 30

Пагинация следует ссылке next. Где заканчивается гарантия этого механизма?

$result = & { do{$r=Invoke-RestMethod $uri;$r.items;$uri=$r.next}while($uri) }
$resultType = if($null -eq $result){'<null>'}else{$result.GetType().FullName}
[pscustomobject]@{ Result=$result; Type=$resultType; Count=@($result).Count }

Клиент должен ограничивать число страниц, проверять повторяющийся токен и агрегировать результаты потоково, чтобы ошибочный API не создал бесконечный цикл. Invoke-RestMethod разбирает JSON и возвращает PowerShell-объекты; статус, заголовки и тело ошибки нужно при необходимости получать через переменные ответа или Invoke-WebRequest. Объект следует сериализовать ConvertTo-Json с достаточной глубиной и передать корректный ContentType; передача самого объекта как Body может стать form-urlencoded. Логируют token/next URL, число страниц и множество уже виденных курсоров; при повторе курсора выполнение прекращают с ошибкой. Успешный ответ без тела не обязан давать объект; код должен опираться на статус и контракт, а не вызывать свойства у $null.

Вопрос 4 из 30

API возвращает 204 No Content. На каком правиле основан результат?

HTTP-статус — часть контракта, но клиент также валидирует схему и доменный статус, не считая любой 2xx полноценным успехом. Клиент должен ограничивать число страниц, проверять повторяющийся токен и агрегировать результаты потоково, чтобы ошибочный API не создал бесконечный цикл. Invoke-RestMethod разбирает JSON и возвращает PowerShell-объекты; статус, заголовки и тело ошибки нужно при необходимости получать через переменные ответа или Invoke-WebRequest. Успешный ответ без тела не обязан давать объект; код должен опираться на статус и контракт, а не вызывать свойства у $null. Параметры запроса нужно URL-кодировать через UriBuilder/HttpUtility или API клиента; обычная интерполяция ломается на &, +, пробелах и Unicode.

Вопрос 5 из 30

URI собирается строковой конкатенацией параметров. Какой вариант точнее выражает контракт?

Клиент должен ограничивать число страниц, проверять повторяющийся токен и агрегировать результаты потоково, чтобы ошибочный API не создал бесконечный цикл. Параметры запроса нужно URL-кодировать через UriBuilder/HttpUtility или API клиента; обычная интерполяция ломается на &, +, пробелах и Unicode. Invoke-RestMethod разбирает JSON и возвращает PowerShell-объекты; статус, заголовки и тело ошибки нужно при необходимости получать через переменные ответа или Invoke-WebRequest. Нужно ограничивать размер ответа, глубину модели и время запроса до разбора; корректный JSON способен исчерпать память. Успешный ответ без тела не обязан давать объект; код должен опираться на статус и контракт, а не вызывать свойства у $null.

Вопрос 6 из 30

Bearer-токен передаётся в Authorization. Как PowerShell обработает этот случай?

$headers=@{Authorization="Bearer $token";Accept="application/json"}
Invoke-RestMethod $uri -Headers $headers

Клиент должен разобрать обе допустимые формы, ограничить ожидание общим deadline и не повторять запросы, которые нельзя безопасно воспроизвести. Заголовок строится как "Bearer <token>", но сам токен нельзя выводить в verbose, transcript или объект ошибки. Условный заголовок предотвращает потерянное обновление: сервер изменяет ресурс только при совпадении версии и обычно отвечает 412 при конфликте. Чувствительные заголовки нельзя безусловно переносить на другой origin; политика перенаправлений должна ограничивать доверенные адреса. Заголовки Authorization, cookies, ключи API и поля секретов редактируют до логирования; удаление после записи уже не устраняет утечку.

Вопрос 7 из 30

If-Match используется с ETag. Какой принцип PowerShell здесь работает?

$headers=@{"If-Match"=$etag}
Invoke-RestMethod $uri -Method Patch -Headers $headers -Body $body -ContentType application/json

Заголовок строится как "Bearer <token>", но сам токен нельзя выводить в verbose, transcript или объект ошибки. Content-Type описывает отправляемое тело, Accept — желаемый формат ответа; отсутствие одного не исправляется значением другого. Invoke-RestMethod разбирает JSON и возвращает PowerShell-объекты; статус, заголовки и тело ошибки нужно при необходимости получать через переменные ответа или Invoke-WebRequest. Условный заголовок предотвращает потерянное обновление: сервер изменяет ресурс только при совпадении версии и обычно отвечает 412 при конфликте. Клиент должен разобрать обе допустимые формы, ограничить ожидание общим deadline и не повторять запросы, которые нельзя безопасно воспроизвести.

Вопрос 8 из 30

Retry-After приходит числом или HTTP-датой. Какое скрытое допущение делает решение ненадёжным?

$retry=$response.Headers["Retry-After"]
$valueType = if($null -eq $retry){'<null>'}else{$retry.GetType().FullName}
[pscustomobject]@{ Value=$retry; Type=$valueType; Count=@($retry).Count }

Клиент должен разобрать обе допустимые формы, ограничить ожидание общим deadline и не повторять запросы, которые нельзя безопасно воспроизвести. Чувствительные заголовки нельзя безусловно переносить на другой origin; политика перенаправлений должна ограничивать доверенные адреса. Content-Type описывает отправляемое тело, Accept — желаемый формат ответа; отсутствие одного не исправляется значением другого. Повтор допустим с Retry-After, backoff, jitter и общим пределом; 429/503 не означают бесконечную безопасную попытку. Условный заголовок предотвращает потерянное обновление: сервер изменяет ресурс только при совпадении версии и обычно отвечает 412 при конфликте.

Вопрос 9 из 30

Content-Type и Accept считаются взаимозаменяемыми. На каком правиле основан результат?

Условный заголовок предотвращает потерянное обновление: сервер изменяет ресурс только при совпадении версии и обычно отвечает 412 при конфликте. Чувствительные заголовки нельзя безусловно переносить на другой origin; политика перенаправлений должна ограничивать доверенные адреса. PowerShell-объект должен явно моделировать требуемую схему: null часто означает «очистить», а отсутствие — «не менять». Заголовок строится как "Bearer <token>", но сам токен нельзя выводить в verbose, transcript или объект ошибки. Content-Type описывает отправляемое тело, Accept — желаемый формат ответа; отсутствие одного не исправляется значением другого.

Вопрос 10 из 30

Пользовательские заголовки копируются в следующий домен при redirect. Какой вывод был бы слишком сильным?

Чувствительные заголовки нельзя безусловно переносить на другой origin; политика перенаправлений должна ограничивать доверенные адреса. Заголовки Authorization, cookies, ключи API и поля секретов редактируют до логирования; удаление после записи уже не устраняет утечку. Заголовок строится как "Bearer <token>", но сам токен нельзя выводить в verbose, transcript или объект ошибки. Клиент должен разобрать обе допустимые формы, ограничить ожидание общим deadline и не повторять запросы, которые нельзя безопасно воспроизвести. Нужно ограничить scheme, host, port и redirect, защищаясь от SSRF к localhost, metadata endpoints и внутренним сетям.

Вопрос 11 из 30

Число идентификатора превышает точность JavaScript-клиента. Что следует сделать до запуска в автоматизации?

$result = [pscustomobject]@{id="9223372036854775807"} | ConvertTo-Json -Compress
$resultType = if($null -eq $result){'<null>'}else{$result.GetType().FullName}
[pscustomobject]@{ Result=$result; Type=$resultType; Count=@($result).Count }

Разделяют DNS/TLS/server time, объём JSON, время десериализации и число страниц; одна общая длительность не указывает узкое место. Нужно ограничивать размер ответа, глубину модели и время запроса до разбора; корректный JSON способен исчерпать память. JSON-объекты семантически не гарантируют порядок ключей; подпись требует канонической сериализации, а не обычного ConvertTo-Json. ConvertTo-Json ограничивает глубину и не является универсальным сериализатором графа; для API формируют DTO без циклов. JSON сам не различает безопасные диапазоны потребителя; крупные идентификаторы лучше передавать строкой, если другая сторона использует IEEE-754 number.

Вопрос 12 из 30

Объект содержит циклические ссылки. Что остаётся непроверенным после успешного запуска?

$a=[pscustomobject]@{Name="a"};$a|Add-Member NoteProperty Self $a
$a|ConvertTo-Json -Depth 5

JSON-объекты семантически не гарантируют порядок ключей; подпись требует канонической сериализации, а не обычного ConvertTo-Json. PowerShell-объект должен явно моделировать требуемую схему: null часто означает «очистить», а отсутствие — «не менять». ConvertTo-Json ограничивает глубину и не является универсальным сериализатором графа; для API формируют DTO без циклов. JSON сам не различает безопасные диапазоны потребителя; крупные идентификаторы лучше передавать строкой, если другая сторона использует IEEE-754 number. Объект следует сериализовать ConvertTo-Json с достаточной глубиной и передать корректный ContentType; передача самого объекта как Body может стать form-urlencoded.

Вопрос 13 из 30

Поля null и отсутствующее поле имеют разный смысл. Какое объяснение не зависит от случайностей окружения?

$result = & { [pscustomobject]@{name="x";description=$null}|ConvertTo-Json }
$summary = [ordered]@{ IsNull=($null -eq $result); Count=@($result).Count }
if($null -ne $result){$summary.Type=$result.GetType().FullName};[pscustomobject]$summary

JSON сам не различает безопасные диапазоны потребителя; крупные идентификаторы лучше передавать строкой, если другая сторона использует IEEE-754 number. ConvertTo-Json ограничивает глубину и не является универсальным сериализатором графа; для API формируют DTO без циклов. Нужно ограничивать размер ответа, глубину модели и время запроса до разбора; корректный JSON способен исчерпать память. PowerShell-объект должен явно моделировать требуемую схему: null часто означает «очистить», а отсутствие — «не менять». Content-Type описывает отправляемое тело, Accept — желаемый формат ответа; отсутствие одного не исправляется значением другого.

Вопрос 14 из 30

Порядок свойств используется как подпись. Какое утверждение верно для этого случая?

Объект следует сериализовать ConvertTo-Json с достаточной глубиной и передать корректный ContentType; передача самого объекта как Body может стать form-urlencoded. JSON-объекты семантически не гарантируют порядок ключей; подпись требует канонической сериализации, а не обычного ConvertTo-Json. Нужно ограничивать размер ответа, глубину модели и время запроса до разбора; корректный JSON способен исчерпать память. JSON сам не различает безопасные диапазоны потребителя; крупные идентификаторы лучше передавать строкой, если другая сторона использует IEEE-754 number. ConvertTo-Json ограничивает глубину и не является универсальным сериализатором графа; для API формируют DTO без циклов.

Вопрос 15 из 30

ConvertFrom-Json получает недоверенное огромное тело. Что остаётся непроверенным после успешного запуска?

PowerShell-объект должен явно моделировать требуемую схему: null часто означает «очистить», а отсутствие — «не менять». JSON сам не различает безопасные диапазоны потребителя; крупные идентификаторы лучше передавать строкой, если другая сторона использует IEEE-754 number. ConvertTo-Json ограничивает глубину и не является универсальным сериализатором графа; для API формируют DTO без циклов. Invoke-RestMethod разбирает JSON и возвращает PowerShell-объекты; статус, заголовки и тело ошибки нужно при необходимости получать через переменные ответа или Invoke-WebRequest. Нужно ограничивать размер ответа, глубину модели и время запроса до разбора; корректный JSON способен исчерпать память.

Вопрос 16 из 30

429 и 503 обрабатываются повтором. Какое объяснение не зависит от случайностей окружения?

foreach($attempt in 1..4){
  try { return Invoke-RestMethod -Uri $uri -ErrorAction Stop }
  catch {
    $status = [int]$_.Exception.Response.StatusCode
    if($status -notin 429,503 -or $attempt -eq 4){ throw }
    $retryAfter = $_.Exception.Response.Headers.RetryAfter.Delta.TotalSeconds
    Start-Sleep -Seconds ([math]::Max($retryAfter,[math]::Pow(2,$attempt)))
  }
}

Повтор допустим с Retry-After, backoff, jitter и общим пределом; 429/503 не означают бесконечную безопасную попытку. HTTP-статус — часть контракта, но клиент также валидирует схему и доменный статус, не считая любой 2xx полноценным успехом. Тайм-аут не показывает, принял ли сервер запрос; повтор способен создать дубль, поэтому нужен idempotency key или проверка результата. Клиент должен разобрать обе допустимые формы, ограничить ожидание общим deadline и не повторять запросы, которые нельзя безопасно воспроизвести. Нужно один раз обновить credential/token при доказанном истечении; бесконечные повторы создают блокировки и скрывают неверные права.

Вопрос 17 из 30

POST без ключа идемпотентности повторяется после тайм-аута. Какое объяснение не зависит от случайностей окружения?

$headers=@{"Idempotency-Key"=$operationId}
$valueType = if($null -eq $headers){'<null>'}else{$headers.GetType().FullName}
[pscustomobject]@{ Value=$headers; Type=$valueType; Count=@($headers).Count }

Тест имитирует тайм-аут после приёма сервером и проверяет idempotency key, а не только сетевой отказ до отправки. HTTP-статус — часть контракта, но клиент также валидирует схему и доменный статус, не считая любой 2xx полноценным успехом. Повтор допустим с Retry-After, backoff, jitter и общим пределом; 429/503 не означают бесконечную безопасную попытку. Тайм-аут не показывает, принял ли сервер запрос; повтор способен создать дубль, поэтому нужен idempotency key или проверка результата. Семантика зависит от операции: «не найдено» при чтении может быть ожидаемым отсутствием, а после создания — нарушением инварианта.

Вопрос 18 из 30

404 для чтения и удаления трактуется одинаково. Какая граница важна для автоматизации?

# Сценарий для ревью: 404 для чтения и удаления трактуется одинаково.
$operationId = [guid]::NewGuid().ToString('N')
$headers = @{ 'Idempotency-Key'=$operationId; Authorization="Bearer $env:API_TOKEN" }
foreach($attempt in 1..3){
  try { Invoke-RestMethod -Method Post -Uri $uri -Headers $headers -Body $body -TimeoutSec 5 -ErrorAction Stop; break }
  catch { if($attempt -eq 3){ throw }; Start-Sleep -Seconds $attempt }
}

Семантика зависит от операции: «не найдено» при чтении может быть ожидаемым отсутствием, а после создания — нарушением инварианта. Повтор допустим с Retry-After, backoff, jitter и общим пределом; 429/503 не означают бесконечную безопасную попытку. Нужно один раз обновить credential/token при доказанном истечении; бесконечные повторы создают блокировки и скрывают неверные права. Заголовки Authorization, cookies, ключи API и поля секретов редактируют до логирования; удаление после записи уже не устраняет утечку. HTTP-статус — часть контракта, но клиент также валидирует схему и доменный статус, не считая любой 2xx полноценным успехом.

Вопрос 19 из 30

401 автоматически повторяется много раз. Что стоит изменить в первую очередь?

Тайм-аут не показывает, принял ли сервер запрос; повтор способен создать дубль, поэтому нужен idempotency key или проверка результата. Повтор допустим с Retry-After, backoff, jitter и общим пределом; 429/503 не означают бесконечную безопасную попытку. Нужно один раз обновить credential/token при доказанном истечении; бесконечные повторы создают блокировки и скрывают неверные права. Invoke-RestMethod разбирает JSON и возвращает PowerShell-объекты; статус, заголовки и тело ошибки нужно при необходимости получать через переменные ответа или Invoke-WebRequest. HTTP-статус — часть контракта, но клиент также валидирует схему и доменный статус, не считая любой 2xx полноценным успехом.

Вопрос 20 из 30

Ответ 200 содержит объект ошибки в теле. Как следует читать этот фрагмент?

Нужно один раз обновить credential/token при доказанном истечении; бесконечные повторы создают блокировки и скрывают неверные права. HTTP-статус — часть контракта, но клиент также валидирует схему и доменный статус, не считая любой 2xx полноценным успехом. Тайм-аут не показывает, принял ли сервер запрос; повтор способен создать дубль, поэтому нужен idempotency key или проверка результата. Успешный ответ без тела не обязан давать объект; код должен опираться на статус и контракт, а не вызывать свойства у $null. Семантика зависит от операции: «не найдено» при чтении может быть ожидаемым отсутствием, а после создания — нарушением инварианта.

Вопрос 21 из 30

Клиент падает только на части ответов. Как исправить причину, а не только симптом?

$r=Invoke-WebRequest $uri -SkipHttpErrorCheck
[pscustomobject]@{Status=$r.StatusCode;Type=$r.Headers["Content-Type"];Length=$r.RawContentLength}

Разделяют DNS/TLS/server time, объём JSON, время десериализации и число страниц; одна общая длительность не указывает узкое место. HTTP-статус — часть контракта, но клиент также валидирует схему и доменный статус, не считая любой 2xx полноценным успехом. Тест имитирует тайм-аут после приёма сервером и проверяет idempotency key, а не только сетевой отказ до отправки. Сравнивают исходный DTO, Depth и результат round-trip; проблема сериализации отделяется от ответа сервера. Сохраняют редактированные status, headers, размер и схему тела; затем воспроизводят минимальный JSON, не записывая токены и персональные данные.

Вопрос 22 из 30

JSON теряет вложенные поля. Какая граница между этими средствами важна?

$json=$dto|ConvertTo-Json -Depth 10;$back=$json|ConvertFrom-Json
$valueType = if($null -eq $json){'<null>'}else{$json.GetType().FullName}
[pscustomobject]@{ Value=$json; Type=$valueType; Count=@($json).Count }

Сравнивают исходный DTO, Depth и результат round-trip; проблема сериализации отделяется от ответа сервера. Тест имитирует тайм-аут после приёма сервером и проверяет idempotency key, а не только сетевой отказ до отправки. ConvertTo-Json ограничивает глубину и не является универсальным сериализатором графа; для API формируют DTO без циклов. Логируют token/next URL, число страниц и множество уже виденных курсоров; при повторе курсора выполнение прекращают с ошибкой. Сохраняют редактированные status, headers, размер и схему тела; затем воспроизводят минимальный JSON, не записывая токены и персональные данные.

Вопрос 23 из 30

Повторный запрос создаёт дубли. Какой принцип PowerShell здесь работает?

# Сценарий для ревью: Повторный запрос создаёт дубли.
$operationId = [guid]::NewGuid().ToString('N')
$headers = @{ 'Idempotency-Key'=$operationId; Authorization="Bearer $env:API_TOKEN" }
foreach($attempt in 1..3){
  try { Invoke-RestMethod -Method Post -Uri $uri -Headers $headers -Body $body -TimeoutSec 5 -ErrorAction Stop; break }
  catch { if($attempt -eq 3){ throw }; Start-Sleep -Seconds $attempt }
}

Тест имитирует тайм-аут после приёма сервером и проверяет idempotency key, а не только сетевой отказ до отправки. Сравнивают исходный DTO, Depth и результат round-trip; проблема сериализации отделяется от ответа сервера. Тайм-аут не показывает, принял ли сервер запрос; повтор способен создать дубль, поэтому нужен idempotency key или проверка результата. Разделяют DNS/TLS/server time, объём JSON, время десериализации и число страниц; одна общая длительность не указывает узкое место. Логируют token/next URL, число страниц и множество уже виденных курсоров; при повторе курсора выполнение прекращают с ошибкой.

Вопрос 24 из 30

Пагинация зациклилась. Какое объяснение не зависит от случайностей окружения?

Сохраняют редактированные status, headers, размер и схему тела; затем воспроизводят минимальный JSON, не записывая токены и персональные данные. Логируют token/next URL, число страниц и множество уже виденных курсоров; при повторе курсора выполнение прекращают с ошибкой. Клиент должен ограничивать число страниц, проверять повторяющийся токен и агрегировать результаты потоково, чтобы ошибочный API не создал бесконечный цикл. Разделяют DNS/TLS/server time, объём JSON, время десериализации и число страниц; одна общая длительность не указывает узкое место. Тест имитирует тайм-аут после приёма сервером и проверяет idempotency key, а не только сетевой отказ до отправки.

Вопрос 25 из 30

Производительность ухудшилась. Какое действие не создаст новой скрытой зависимости?

Логируют token/next URL, число страниц и множество уже виденных курсоров; при повторе курсора выполнение прекращают с ошибкой. Нужно ограничивать размер ответа, глубину модели и время запроса до разбора; корректный JSON способен исчерпать память. Сравнивают исходный DTO, Depth и результат round-trip; проблема сериализации отделяется от ответа сервера. Разделяют DNS/TLS/server time, объём JSON, время десериализации и число страниц; одна общая длительность не указывает узкое место. Сохраняют редактированные status, headers, размер и схему тела; затем воспроизводят минимальный JSON, не записывая токены и персональные данные.

Вопрос 26 из 30

Токен попал в журнал запроса. Какой вывод можно подтвердить?

$safeHeaders=@{};$headers.Keys|ForEach-Object{$safeHeaders[$_]=if($_ -match "Authorization|Cookie|Key"){"[REDACTED]"}else{$headers[$_]}}

Заголовки Authorization, cookies, ключи API и поля секретов редактируют до логирования; удаление после записи уже не устраняет утечку. Заголовок строится как "Bearer <token>", но сам токен нельзя выводить в verbose, transcript или объект ошибки. Недоверенные данные валидируют по схеме и передают типизированным API; Invoke-Expression и неконтролируемые пути недопустимы. SkipCertificateCheck устраняет проверку подлинности и делает TLS уязвимым для подмены; рабочая среда должна доверять правильной цепочке и имени. Используют SecretManagement, managed identity или защищённое хранилище с ротацией и минимальными правами.

Вопрос 27 из 30

Клиент принимает любой сертификат. Какое утверждение верно для этого случая?

# Сценарий для ревью: Клиент принимает любой сертификат.
$policy = Get-ExecutionPolicy -List
$signature = Get-AuthenticodeSignature -FilePath .\deploy.ps1
[pscustomobject]@{ Policy=$policy; Status=$signature.Status; Signer=$signature.SignerCertificate.Subject }
if($signature.Status -eq 'Valid'){ & .\deploy.ps1 }

Клиент должен ограничивать число страниц, проверять повторяющийся токен и агрегировать результаты потоково, чтобы ошибочный API не создал бесконечный цикл. SkipCertificateCheck устраняет проверку подлинности и делает TLS уязвимым для подмены; рабочая среда должна доверять правильной цепочке и имени. Недоверенные данные валидируют по схеме и передают типизированным API; Invoke-Expression и неконтролируемые пути недопустимы. Нужно ограничить scheme, host, port и redirect, защищаясь от SSRF к localhost, metadata endpoints и внутренним сетям. Используют SecretManagement, managed identity или защищённое хранилище с ротацией и минимальными правами.

Вопрос 28 из 30

URI для запроса приходит от пользователя. Почему локальный успех ещё ничего не доказывает?

# Сценарий для ревью: URI для запроса приходит от пользователя.
$operationId = [guid]::NewGuid().ToString('N')
$headers = @{ 'Idempotency-Key'=$operationId; Authorization="Bearer $env:API_TOKEN" }
foreach($attempt in 1..3){
  try { Invoke-RestMethod -Method Post -Uri $uri -Headers $headers -Body $body -TimeoutSec 5 -ErrorAction Stop; break }
  catch { if($attempt -eq 3){ throw }; Start-Sleep -Seconds $attempt }
}

Недоверенные данные валидируют по схеме и передают типизированным API; Invoke-Expression и неконтролируемые пути недопустимы. SkipCertificateCheck устраняет проверку подлинности и делает TLS уязвимым для подмены; рабочая среда должна доверять правильной цепочке и имени. Заголовки Authorization, cookies, ключи API и поля секретов редактируют до логирования; удаление после записи уже не устраняет утечку. Нужно ограничивать размер ответа, глубину модели и время запроса до разбора; корректный JSON способен исчерпать память. Нужно ограничить scheme, host, port и redirect, защищаясь от SSRF к localhost, metadata endpoints и внутренним сетям.

Вопрос 29 из 30

Ответ API напрямую используется как команда или путь. Какое объяснение точнее?

Недоверенные данные валидируют по схеме и передают типизированным API; Invoke-Expression и неконтролируемые пути недопустимы. Invoke-RestMethod разбирает JSON и возвращает PowerShell-объекты; статус, заголовки и тело ошибки нужно при необходимости получать через переменные ответа или Invoke-WebRequest. Нужно ограничить scheme, host, port и redirect, защищаясь от SSRF к localhost, metadata endpoints и внутренним сетям. Используют SecretManagement, managed identity или защищённое хранилище с ротацией и минимальными правами. Заголовки Authorization, cookies, ключи API и поля секретов редактируют до логирования; удаление после записи уже не устраняет утечку.

Вопрос 30 из 30

Секрет хранится в JSON-конфигурации рядом со сценарием. На каком правиле основан результат?

Нужно ограничить scheme, host, port и redirect, защищаясь от SSRF к localhost, metadata endpoints и внутренним сетям. Заголовки Authorization, cookies, ключи API и поля секретов редактируют до логирования; удаление после записи уже не устраняет утечку. Используют SecretManagement, managed identity или защищённое хранилище с ротацией и минимальными правами. Недоверенные данные валидируют по схеме и передают типизированным API; Invoke-Expression и неконтролируемые пути недопустимы. Сохраняют редактированные status, headers, размер и схему тела; затем воспроизводят минимальный JSON, не записывая токены и персональные данные.